# A SaaS plus a service: packaging software with onboarding and expertise

> Turn a finished SaaS and your expertise into a clear offer. Separate software access, onboarding and recurring help, then test the hours it takes to deliver.

Source: https://saascode.ai/inside/saas-plus-service-business · Published: 2026-09-28 · Section: use-case

---
A SaaS plus service business combines recurring access to software with a defined amount of human help. It works as an offer when the software handles a valuable recurring job and the service helps a particular customer get started, make better decisions, or complete work they want to delegate.

The important choice is what you will keep doing for each customer. A setup session has an end. A monthly review consumes capacity every month. Running the customer's operation for them is a different promise again. Price and describe those commitments separately, even if you sell them together.

A finished SaaS can supply the application behind this offer. Your expertise supplies the service layer. The example below shows how to combine them without leaving the scope or your calendar open-ended. It is a fictional offer, with illustrative hours and prices, not a SaaSCode service package or a reported customer result.

## Choose the job your service adds to the software

Imagine an independent training studio that already needs a system for booking introductory sessions. The manager can use a suitable scheduling application, but needs help choosing an appointment structure, setting availability, and teaching an assistant how to handle changes.

You could offer three different services around the same application:

| Customer need | Service you could sell | Who performs the recurring work? |
|---|---|---|
| “Help us get started properly.” | A finite configuration and training package | The studio, after handover |
| “Help us improve how we use it.” | A scheduled review of one workflow, with a bounded adjustment | The studio, with your advice |
| “Handle our bookings for us.” | An ongoing administrative service using the software | Your team, within agreed coverage |

These are different businesses to operate. The third requires staffing for customer work, not just product support. Pick the one you can deliver reliably and name it plainly.

For this example, choose setup plus an optional monthly review. The studio still handles its appointments. Your service helps it use the system; it does not promise to fill classes or answer every learner's message.

There are established examples of software vendors offering a distinct onboarding service. [HubSpot's onboarding page](https://www.hubspot.com/services/onboarding) describes technical and strategic guidance tailored to goals, organizational complexity, purchased products and the existing technology stack. That is evidence of a defined assistance layer, not evidence that its offer, pricing or results will transfer to your business.

If you have not established that the recurring job matters to a buyer, start with the [first-customer and paid-pilot guide](/inside/first-paying-customers-for-a-niche-saas). This article addresses the next decision: how to package and staff an offer once you have a plausible customer and workflow.

## Put three boundaries in the offer

Write down what the application provides, when onboarding is complete, and how much ongoing human attention the customer can buy. A single subscription price can still communicate these boundaries. The delivery team needs them regardless of how the invoice is arranged.

![Three parts of an illustrative offer: application access continues, onboarding ends at an agreed handover, and an optional monthly review has a time budget.](https://hpcxvndsvdynlbperiah.supabase.co/storage/v1/object/public/content/own-blog/saas-plus-service-business/three-parts-of-the-offer-522a345f.svg)

*Original editorial diagram: software access, a finite setup package and recurring expertise carry different commitments.*

Here is a concrete version for one studio, using a hypothetical implementation that has already been checked for the described booking workflow. Every limit is a proposed scope choice, not a default capability of every SaaSCode product.

| Offer component | Included in this example | Boundary |
|---|---|---|
| Ongoing application access | One studio workspace for the manager and one assistant; the agreed booking workflow | Available features and usage limits are stated on the offer page |
| One-time onboarding | One workflow discussion, configuration of one appointment type and availability pattern, one training session, and a short handover note | Up to four provider hours in total, including preparation and follow-up |
| Optional monthly review | Review one booking-workflow issue, meet for 30 minutes and make one supported configuration adjustment | One hour total per month, including preparation and follow-up; extra work is quoted separately |
| Product support | A channel for questions and reports about the supplied application | Published support hours and an achievable response target; no implied round-the-clock coverage |
| Separate work | Historic-data cleanup, custom integrations, new features, extra staff training, or handling appointments on the studio's behalf | A separate estimate and explicit agreement before work begins |

Do not turn the four-hour setup budget into an invitation to leave half a setup behind. First confirm that the customer fits the package: one agreed workflow, a designated manager, the necessary information and no unknown migration. If discovery exposes extra work, revise the scope before committing to the package.

Define the handover in terms of a task the customer can perform. The manager should be able to create availability, make a test booking, change it and explain how the assistant should handle an exception. Agree on that task in advance and record the result. A call ending is not, by itself, evidence that onboarding is complete.

Also state what happens when the customer delays providing information, misses a session or needs another appointment type. For the monthly review, explain scheduling, whether unused time carries over, and how cancellation affects future reviews. Keep these terms consistent with what you actually sell and deliver.

## Keep the software purchase separate from your customer promise

SaaSCode sells finished applications as source code for you to deploy and operate. It does not host the purchased application for you. The current [purchase, licence and support terms](/terms) distinguish operating your own product from client deployments and prohibit redistributing the underlying source code. Choose the licence for your intended deployment arrangement; selling your expertise does not expand those rights.

Your customer may be buying access to your hosted service, while you are buying the application behind it. Those are separate transactions. Alternatively, you may be delivering a deployment for a client. Make that operating arrangement clear before deciding who controls the domain, infrastructure accounts and customer data.

SaaSCode's standard support does not include your hosting setup, data migration, custom modifications or on-call operation. If you offer those services to your own customers, assign and cost the work on your side. The [source-code purchase guide](/inside/buy-saas-source-code) explains the handover; the [launch sequence](/inside/launch-a-saas-from-source-code) helps turn the application into an operating service.

This is where a finished product can be useful: you can concentrate your expertise on a customer workflow that the application already supports. Compare the actual product documentation and demo with the promised task before selling it. If delivering the package requires a new subsystem, record that as product development rather than hiding it inside onboarding.

## Test the monthly capacity before selling more accounts

The one-time setup package and the monthly review compete for the same delivery hours. Count both, including work that happens outside calls.

Suppose you can allocate **40 hours per month** to customer delivery after reserving separate time for sales, administration and product development. Use these planning assumptions:

- Reserve 10 hours for application support and operational work.
- Keep 6 hours uncommitted for variability and unexpected work.
- Budget 1 hour for each customer's monthly review, including preparation, the call and follow-up.
- Budget 4 hours for each new onboarding package, including all preparation and handover work.

That leaves **24 planned service hours**. With eight active review customers and four new onboardings, the calculation is:

**8 × 1 hour + 4 × 4 hours = 24 hours.**

The full month is then 10 hours of support and operations, 24 hours of planned service delivery, and 6 hours of reserve. Those are distinct allocations; the reserve is not another block you have already sold.

![A 40-hour monthly capacity budget allocates 10 hours to operations, 8 to reviews, 16 to onboarding and 6 to reserve; a longer-onboarding scenario exceeds capacity by 2 hours.](https://hpcxvndsvdynlbperiah.supabase.co/storage/v1/object/public/content/own-blog/saas-plus-service-business/service-capacity-budget-27805ad1.svg)

*Illustrative capacity arithmetic, not measured delivery performance. The reserve absorbs variation; it is not advertised customer time.*

Now stress the assumption. If each onboarding takes six hours instead of four, planned service work rises to **8 + 24 = 32 hours**. Add the 10 operating hours and you need 42 hours before keeping any reserve: two hours more than the available month. The original six-hour reserve cannot cover an eight-hour overrun.

You would need to reduce new starts, narrow the repeatable scope, add delivery capacity or change the offer. For example, with six-hour onboardings and the original reserve intact, two new starts plus eight reviews use 20 of the 24 planned service hours; three starts would use 26. This is why a waiting list can be more honest than accepting every setup request immediately.

These assumptions will change as the customer base grows. Support and operations are not permanently fixed at 10 hours. Track them separately, along with time per onboarding and per review. Recalculate using actual delivery records before expanding the number of accounts.

## Price the service without hiding its labor

You can charge an onboarding fee and an optional service add-on alongside software access. You can also sell one combined plan. In either case, keep an internal record of what portion of the price must fund human work.

Consider an illustrative **$300 setup fee** and a **$90 monthly review add-on**. These are arbitrary planning inputs, not market rates or recommended prices. If you value delivery labor at **$40 per hour**, a four-hour setup uses $160 of that budget, leaving $140 before other costs. At six hours, labor uses $240 and leaves $60.

The one-hour review uses $40 and leaves $50 before other costs. If it quietly becomes three hours through messages and extra changes, the $120 labor allowance exceeds the $90 add-on price. That is a scope problem even if the customer is delighted.

None of these differences is net profit. Payment costs, tools, acquisition, management time and other expenses still need funding. Hosting and application support also need coverage in the overall offer. Use the [SaaS launch-cost guide](/inside/saas-launch-costs) to place those responsibilities alongside service delivery instead of counting the same hour in two budgets.

For a combined plan, ask a useful question: if the customer stopped needing the human service, what would remain worth paying for? The answer helps distinguish recurring application value from a temporary need for assistance. You might retain software access, offer periodic reviews, or conclude that this customer needed a finite implementation project.

## Route extra requests before they become the package

During delivery, a customer will ask for something that was not in the original offer. Classify the request before agreeing to it.

An explanation of an existing setting belongs in the appropriate support or training scope. A supported adjustment may fit the monthly review's agreed time budget. A new integration needs a separate estimate. Asking your team to contact every attendee is an operational service, with its own coverage and staffing requirements.

Do not charge a customer an implementation fee merely because they reported a defect in what you promised. Handle defects under the support and commercial commitments you made. Equally, avoid promising an unlimited service in the sales conversation and trying to enforce a narrow time limit after payment.

A useful reply to an extra request could be:

> We can cover the availability change in this month's review. Connecting the other calendar is outside that package, so we will first check what the integration requires and send a separate scope. Would you like us to prepare that estimate?

This is sample wording, not a message sent to a customer. It makes the next decision explicit without forcing every request into product development.

## Start with one repeatable offer

Choose one audience, one application workflow and one service promise. Write the included work and handover task, estimate the actual delivery hours, and test the same package with a small number of suitable customers. Record where the time goes and which help they still need after setup.

If customers keep needing your judgment, a bounded advisory service may be part of the recurring offer. If they become independent, a strong onboarding package may be enough. If they want you to do their daily work, decide deliberately whether you want to run that service business.

Explore the [SaaSCode catalog](/products) against that specific workflow. Start from what the finished product demonstrably does, then add expertise you can explain, schedule and deliver. The result should be a clear operating offer: useful software, a defined human contribution, and enough capacity to keep the promise.