How Should You Package Services Alongside Your Software?
How Should You Package Services Alongside Your Software?
Charge for implementation, keep it small relative to subscription revenue, and design every service so it is trying to make itself unnecessary. Services exist to get customers to value faster. The moment they exist to hit a revenue number, they start competing with the product for attention and the margin goes with them.
We should declare a bias up front. We run a services business, so we are not neutral about whether services have value. What we are wary of is software companies drifting into becoming agencies without deciding to.
That drift is common and it happens one reasonable yes at a time.
Why Do Software Companies Resist Selling Services?
Because of margin and because of how investors read the revenue line. Subscription revenue is repeatable and highly valued. Services revenue is delivered by people, does not repeat on its own, and dilutes blended gross margin.
The resistance is rational and frequently overdone. Refusing to sell implementation does not remove the implementation work, it just moves it. Either your customer does it badly, your customer success team does it for free, or your sales cycle stretches while the buyer tries to work out who will.
The useful question is not whether to do services, it is who pays for them and whether that is deliberate.
What Are Services Actually For?
Removing the reasons a good-fit customer fails to get value. That is the whole brief, and it gives you a test for every service you consider offering.
In practice there are four kinds. Implementation, which gets the thing running. Migration, which moves them off whatever they had. Enablement, which teaches their team. And ongoing advisory, which is the one that most often turns into an agency.
The first three have a natural end, which is what makes them healthy. Advisory does not, which is why it needs the tightest boundaries. If you offer it, scope it to a defined outcome rather than to a monthly retainer of unspecified help.
Should Implementation Be Free, Paid, or Bundled?
Paid, in almost every case, and here is the argument that usually wins internally. Free implementation is not perceived as generous, it is perceived as low value, and it removes the customer's obligation to show up.
The practical failure of free implementation is scheduling. When it costs nothing, the customer's project team deprioritises it, the rollout slips, and your onboarding period ends with a customer who has not yet used the product. Paid engagements get calendar time.
Where free makes sense is at the small end, where the implementation genuinely takes an hour and charging for it costs more in process than it recovers. Draw that line by effort, not by deal size, and write it down so sales is not negotiating it per deal. Our notes on the surrounding structure are in structuring pricing tiers.
How Much Services Revenue Is Too Much?
There is a usable benchmark for this. SaaS Capital's fifteenth annual survey, completed in March 2026 with more than 1,000 SaaS companies responding and published in June 2026, puts the median professional services cost of goods sold at 5 percent of ARR.
That sits alongside their other medians, which are worth holding in view together: sales at 15 percent of ARR, marketing at 8 percent, research and development at 22 percent, general and administrative at 15 percent, customer support and success at 9 percent, hosting at 5 percent, DevOps at 4 percent and other cost of goods sold at 3 percent.
What that tells you is the shape of a normal software company. Services delivery is a real cost line but a small one, sitting well below what these companies spend on building and selling the product. If your services cost line is drifting towards the size of your R&D line, you have changed business without a board meeting about it.
The same survey found 83 percent of bootstrapped companies operating within two percentage points of breakeven or profitable, against 52 percent of equity-backed firms, which is a useful reminder that the right answer here depends on whose money is funding the gap.
How Do You Price a Service Without Becoming an Agency?
Price fixed, scope narrow, publish the shape. Hourly pricing is what turns a software company into an agency, because it makes every engagement negotiable and every scope elastic.
A fixed price for a defined outcome does three things. It forces you to standardise delivery, because your margin now depends on it. It makes the service comparable to the subscription, so buyers can evaluate it. And it caps the customer's exposure, which removes the main objection.
Publishing the shape matters even if you do not publish the number. Buying groups average around ten people, and 6sense's research found roughly 40 percent of them come from outside the intended end-user department, so finance and procurement are in the room. A service with no published structure reads as an open-ended cost to exactly those people.
When Should a Service Become a Feature?
As soon as you have delivered it more than a handful of times the same way. That is the discipline that separates a healthy services function from a slowly growing consultancy.
Every repeated service is a product requirement that has not been built yet. Data migration done by hand fifteen times is an import tool. Configuration workshops run forty times are a setup wizard and a template library. The services team's real output should include a steady stream of these observations.
Build that into how the team reports. A quarterly list of what was delivered repeatedly, handed to product as candidates, keeps the relationship healthy. Without it, services quietly becomes the place where product gaps go to be absorbed by humans forever.
Who Should Deliver It?
You first, partners later, and the transition should be planned rather than triggered by overload. Delivering it yourself early is how you learn what the service actually is, and that knowledge is what makes a partner programme possible.
Move to partners when the service is standardised enough to be documented, when demand exceeds what you want to staff, or when it needs local presence you do not have. Moving earlier than that exports a process you have not defined, and the customer experiences the result as your product being hard to implement.
Keep at least some delivery in-house permanently, even after partners take the volume. It is your best source of unfiltered information about where the product is hard, and the first thing you lose when you outsource entirely.
What Does This Do to Your Sales Motion?
It slows the deal and improves the retention, which is a trade most companies should take. Adding a paid implementation to a proposal adds a conversation, and that conversation surfaces the objections that would otherwise have shown up as a stalled rollout.
Be careful with one specific failure. When services become a lever sales uses to close, they get discounted away or given free, and you end up delivering the work anyway without the revenue or the customer commitment. If services can be discounted freely, they will be. Our view on that dynamic is in discounting to close a deal.
The version that works is services as a requirement for certain deal shapes rather than an optional add-on. Above a certain complexity, implementation is part of the package, not a line to negotiate.
What Would We Do at Each Stage?
Early on, do the services yourself, charge something, and treat every engagement as research. You are not building a services business, you are learning what your product assumes and finding out where those assumptions break.
In the growth stage, standardise and productise. Fixed scopes, published shapes, a named owner, and a routine for feeding repeated work back into the roadmap. Watch the cost line against benchmarks like the 5 percent median so you notice drift early.
At scale, decide deliberately what stays in-house and what goes to partners, and keep the boundary written down. The companies that get this wrong did not choose to become services businesses. They just never chose not to. A clear expansion motion depends on that clarity, which is part of why we wrote about how land and expand actually works.
If you are trying to work out what belongs in your product, your services, and your partners, we are happy to think it through with you. Come and find us at phoenix.studio.
Want a site that performs like this?
Tell us about your project. We will come back with a clear next step, no pressure.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Have a project like this?
Tell us where you want to go. We'll tell you how we'd get you there.