From Madhur Jain | Product & Market Analysis
Services-as-Software: Selling the Outcome Instead of the Licence
On this page
Software has spent thirty years selling tools that make people more productive. Services-as-software sells the completed work instead. The buyer does not learn the product, configure it or staff it, and the invoice arrives per outcome rather than per licence. That shift changes the addressable budget from software spend to labour spend, which is roughly ten times larger and considerably harder to win.
Key takeaways
- The comparison changes from software to salary. A product delivering completed work is priced against a labour budget, which is far larger than any software budget.
- Margins look worse and revenue per customer looks better. Delivery cost sits inside gross margin, so these businesses do not resemble classic software financially.
- Liability moves with the work. A vendor delivering an outcome carries responsibility a tool vendor never did, and most contracts have not caught up.
- Verification is the product. Where the work has consequences, the checking layer rather than the generation is what buyers are actually paying for.
What the model actually is
Software-as-a-service sells access to a tool. The customer supplies the people, the process and the judgement, and the vendor supplies capability.
Services-as-software sells the finished work. The customer supplies the input and the acceptance decision, and the vendor supplies everything in between.
The distinction is not about AI. Business process outsourcing has sold outcomes for decades. What changed is that the delivery is now performed by software at software margins rather than by people at services margins, which is why the model became interesting to investors who would never have funded an outsourcing company.
Why it became possible now
Three conditions had to hold simultaneously, and they only did recently.
The work had to be doable without a person. Not assisted, done. Drafting, extraction, review, reconciliation and triage crossed that line for a meaningful share of cases.
The output had to be checkable. Selling an outcome requires knowing whether the outcome was correct. Categories where correctness is unverifiable cannot support this model regardless of capability.
The unit cost had to be low enough. Delivering completed work consumes compute per unit, so the economics only function where the price per outcome comfortably exceeds the cost per outcome, a constraint examined in the analysis of AI margins.
The economics are genuinely different
This is the part that surprises people who model these companies as software.
A services-as-software business has real cost of delivery: inference, verification, escalation handling and often human review for the cases the system declines. That produces gross margins below classic software and well above professional services.
The compensating advantage is revenue per customer. A product replacing labour captures a share of a budget an order of magnitude larger than the software line it sits next to. Lower margin on much larger revenue frequently produces a better business, and it produces a very different-looking one.
Investors who benchmark these companies against software margins will conclude they are inferior. Investors who benchmark them against services margins will conclude the opposite. Both comparisons are wrong and both are being made constantly.
Why investors keep mispricing these companies
A software investor sees a 55% gross margin and marks the company down against a category norm of 75%. A services investor sees the same number and marks it up against a norm of 35%.
Neither comparison is informative. The relevant question is revenue per customer against cost to serve, and on that measure a services-as-software company frequently outperforms both comparators while resembling neither.
Founders in this category spend a disproportionate amount of time explaining why their margin structure is not a problem, which is a sign the category still lacks its own benchmarks.
The liability question nobody has settled
Selling a tool carries almost no liability for outcomes. The customer chose how to use it.
Selling a completed outcome is different in kind. If the vendor performed the work, the vendor is closer to responsible for the work being wrong, and most software contracts were drafted on the assumption that would never happen.
Three questions decide the exposure and most agreements answer none of them: what constitutes a defective outcome, what remedy applies, and whether liability is capped at fees paid or at the consequence of the error.
Professional services firms solved this decades ago with engagement letters, professional indemnity insurance and defined standards of care. Software companies entering this model are rediscovering those instruments, generally after their first serious dispute.
The clauses to write before the first enterprise deal
| Clause | What it must define | Why it matters |
|---|---|---|
| Defective outcome | What counts as work not correctly completed | Without it, every dispute is a negotiation from scratch |
| Remedy | Rework, credit or refund, and within what window | Determines whether a failure costs you margin or reputation |
| Liability cap | Fees paid, or consequence of the error | The single largest financial exposure in the model |
| Standard of care | What level of accuracy is being promised | Professional services solved this decades ago; software has not |
| Escalation definition | When the vendor may decline to complete work | Prevents the buyer sending only the hardest cases |
How it actually gets priced
Pure outcome pricing is the model everyone describes and a minority of companies actually run.
The clearest reference point is support, where per-resolution pricing around $0.99 has been widely cited. It is clean, aligned and immediately raises the definitional question of what counts as a resolution.
Most companies land somewhere less pure. Hybrid models reached roughly 37% of the market, and the typical services-as-software structure is a platform fee covering onboarding and integration, plus a per-outcome charge, plus an escalation rate for cases requiring human handling.
That third component is the one buyers should scrutinise. A low headline per-outcome price with an expensive escalation rate produces a bill that depends entirely on how often the system declines to complete the work, which is a number only the vendor can see.
Why the sales motion is harder
Selling a tool means finding a budget holder who wants capability. Selling an outcome means displacing something a person or a firm currently does.
That is a slower, more political sale. It touches headcount plans, existing vendor relationships and someone's professional judgement about whether the work can be done this way at all.
It also requires proof at a standard software never faced. A buyer replacing a licence compares features. A buyer replacing labour compares error rates, and asks what happens on the day it gets something wrong.
The practical consequence is longer cycles, larger contracts and a pilot phase that functions as an audition rather than an evaluation. Companies that price and staff for a software sales motion consistently underestimate all three.
Where the model fails
Four situations, and they are predictable enough to avoid.
Unverifiable outcomes. If nobody can say whether the work was done correctly, per-outcome pricing becomes per-attempt pricing with better marketing.
Highly variable inputs. The economics assume a distribution of case complexity. A customer sending only the hard cases breaks the unit economics without breaching any term.
Regulated judgement. Where a qualified person must sign, the vendor cannot deliver the outcome. It can deliver everything up to the signature, which is a different and smaller product.
Low-value work. Per-outcome pricing needs the outcome to be worth enough to justify a transaction. Work worth pennies cannot support the overhead of pricing it individually.
Who this affects first
Not evenly, and the sequence is predictable from the three-jobs analysis.
The sequence
Products whose primary value is monitoring go first, because that job transfers cleanly and completely. Anything that exists to tell a person when a threshold was crossed is competing with something that never stops watching.
Products whose value is exploration go slowly, because human curiosity does not reduce to a defined query and people genuinely enjoy looking at their data.
Products whose value is evidence and justification grow, because the number of actors making decisions is increasing and every one of them creates something that needs explaining afterwards.
If your product does all three, the useful exercise is working out what share of usage each represents. Most teams have never measured it and are surprised by the answer.
Where this argument is weak
Three honest problems.
The labour budget argument is a pitch as much as an analysis. Buyers do not have a single pot of money marked labour that software can access. Displacing a salary requires a headcount decision, which is slower, more political and more reversible than a software purchase.
The evidence base is also thin and concentrated. Support and legal produce most of the examples because both have countable outputs and expensive practitioners. Whether the model generalises to work that is neither is untested.
And the margin structure may improve less than expected. Verification and escalation costs are the ones that do not fall with model improvement, because a better model reduces the number of errors and does not reduce the need to check for them.
Frequently asked questions
What is services-as-software?
It is a model where the vendor sells completed work rather than access to a tool. The customer supplies the input and the acceptance decision, and the vendor supplies everything in between. The distinction from traditional outsourcing is that delivery is performed by software rather than people, which changes the cost structure fundamentally.
How is it different from SaaS?
Traditional SaaS sells a tool and the customer supplies the people, process and judgement to use it. Services-as-software sells the finished output. The pricing comparison changes from a software budget to a labour budget, which is roughly an order of magnitude larger, and delivery cost moves inside the vendor's gross margin.
Why are services-as-software margins lower than SaaS?
Because delivering completed work has real per-unit cost: inference, verification, escalation handling and often human review of declined cases. That produces gross margins below classic software and well above professional services. The compensating advantage is much higher revenue per customer, since the product competes with salaries rather than licences.
Who is liable when the outcome is wrong?
Largely unsettled. Selling a tool carries almost no liability for outcomes because the customer chose how to use it. Selling a completed outcome moves the vendor closer to responsibility, and most software contracts were drafted assuming that would not happen. Three questions decide exposure: what counts as defective, what remedy applies, and whether liability is capped at fees or at consequence.
How is services-as-software priced?
Rarely as pure outcome pricing, despite the description. The typical structure is a platform fee covering onboarding and integration, a per-outcome charge, and an escalation rate for cases requiring human handling. Buyers should scrutinise the third component, since a low per-outcome price with expensive escalations produces a bill driven by a number only the vendor sees.
Where does the model not work?
Four situations. Where outcomes cannot be verified, per-outcome pricing becomes per-attempt pricing. Where input complexity varies wildly, a customer sending only hard cases breaks the economics. Where a qualified person must legally sign, the vendor cannot deliver the outcome. And where the work is worth too little to justify pricing each instance.
Where to start this week
If you are evaluating a services-as-software vendor, ask two questions before anything about capability.
What exactly counts as a completed outcome, in writing, and who decides? And what is the escalation rate and what does an escalated case cost? Those two answers determine your bill more than the headline price does.
If you are building one, write the defective-outcome definition into your contract before your first enterprise deal rather than after your first dispute. Professional services firms solved this decades ago and the instruments are well established. Borrowing them is faster than rediscovering why they exist.
References
- Growth Unhinged, The 2026 state of B2B SaaS and AI monetization report, May 2026. Used for hybrid and outcome pricing shares and the Fin per-resolution reference.
- Value Add VC, Harvey AI valuation 2026: $11B and $190M ARR, June 2026. Used for the vertical AI pricing comparison against labour budgets.
- SaaS Mag, Vertical AI agents are eating horizontal SaaS in 2026, June 2026. Used for the outcome-selling pattern.
- The SaaS Library, B2B SaaS trends in 2026, May 2026. Used for pricing structure analysis.
The margin comparison in this post is a structural assessment rather than measured company data. No consistent public reporting exists comparing delivery costs across these models, and the evidence base is heavily concentrated in support and legal.
Related reading