There's a version of the software sale that most SaaS companies still haven't properly reckoned with.
First, you sold perpetual licences. Then you sold annual subscriptions, and the renewal conversation shifted from "would you like to upgrade?" to "did we deliver enough value that you'll pay again?" Then you started selling seats or usage, which made the expansion motion more interesting and the churn signal clearer.
Now (slowly, then all at once) some parts of the market are selling outcomes.
Not "access to the platform." Not "a licence for 50 seats." But: "we will deliver X measurable result, and our contract is structured around whether we achieve it." Risk-sharing clauses. Milestone payments. SLAs tied not to uptime but to business performance.
If you're not seeing this in your market yet, you probably will. And if you are seeing it (in enterprise deals, in pilots, in procurement conversations where the buyer pushes back on "value delivered" as too vague), then you're already in the early stages of a significant shift in how CS operates.
Why this is happening
The short answer: buyers have more data and less patience.
The long version: fifteen years of SaaS consolidation means most large enterprises are managing a sprawling stack of tools they don't fully use, from vendors who all claim to deliver ROI and almost none of whom can prove it. The procurement function at those companies is tired. They've paid for transformation that didn't transform. They've renewed software nobody logged into. They're not interested in another slide deck with a testimonial quote.
The natural response (and it's starting to happen) is to push the risk back onto the vendor. If you're so confident in your ROI, put some of it in the contract.
This is uncomfortable for most SaaS companies. It's very uncomfortable for most CS teams, who are used to being accountable for adoption and satisfaction but not for the downstream business outcomes those things are supposed to produce.
What changes when the contract is outcome-based
The obvious thing that changes is accountability. If you've promised a measurable outcome and you're not on track to deliver it, that's no longer a "customer health" conversation. It's a contractual one, with implications for revenue recognition, renewals, and in some cases liability.
But the less obvious change is the one that catches most CS teams off guard: the entire motion has to move upstream.
In a standard SaaS relationship, CS tends to be reactive in the first six months (solve the onboarding problems), proactive in the middle (drive adoption, surface expansion signals), and transactional at renewal (build the business case retrospectively). The outcome is defined vaguely ("value delivered"), and the customer's job is to accept whatever narrative the CSM constructs.
With an outcome-based contract, none of that works.
The outcome has to be defined precisely before the sale closes, because "we will deliver a 20% reduction in manual processing time" is a fundamentally different commitment from "we'll help you get the most from the platform." That definition happens in the sales cycle, which means CS has to be involved in the sales cycle. Not as a support function that inherits the deal, but as the function that determines whether the promised outcome is actually achievable and how it will be measured.
Then the motion has to be structured around measurement from day one. You need a baseline. You need agreed checkpoints. You need a shared definition of what constitutes delivery. You need a data pipeline that can produce evidence, not anecdotes.
And then (and this is the hard part), you need a team that can have an honest conversation with the customer when the trajectory is wrong. Not "we're on track, don't worry" but "we're twelve weeks in and the data suggests we're going to miss the Q3 milestone unless we do X. Here's what X looks like." That's a different conversation, with different stakes, from anything most CSMs have been trained for.
The three things CS ops needs to build
If your business is moving toward outcome-based contracts, or if your customers are starting to ask for them, there are three structural things that need to exist before you commit.
A pre-sale scoping process. CS ops needs to own a framework that the sales team uses to assess feasibility before the outcome is promised. What data will we need? Who owns it on the customer side? What's the realistic range of outcomes given what we know about this customer's starting point? This isn't about slowing down deals. It's about not closing deals you can't win.
A measurement infrastructure. Not dashboards. An actual agreed methodology for measuring the outcome, baseline to result. This includes: what counts as success, how the data will be collected, who validates it, and what happens if there's disagreement about the numbers. This needs to be in the contract and in the hands of the CSM before the kickoff call.
A risk escalation protocol. When a customer is off track on a milestone, what happens? Who does the CSM escalate to? What authority does that person have? What's the remediation playbook? "We'll work harder" is not a protocol. Most CS teams don't have one, because most CS teams have never needed one. You need it before you need it.
The cultural shift is harder than the process shift
Here's the thing most CS leaders don't say out loud: a lot of CSMs are not comfortable being on the hook for outcomes they can't fully control.
This is understandable. The customer's adoption of your platform is partly in your hands. Their business outcomes are not, at least not fully. Market conditions change. Leadership priorities shift. The team that was supposed to run the programme gets restructured. The CSM does everything right and the outcome doesn't materialise anyway.
Outcome-based contracts need to be structured carefully to account for this: there need to be clauses about customer commitments, about what the vendor controls versus what the customer controls, about force majeure conditions. Those are legal and commercial questions.
But beneath the contract language is a cultural question: is your CS team built to operate with this level of accountability? Are your CSMs equipped to have the hard conversations? Are your managers equipped to coach those conversations rather than smoothing them over?
The teams that will do this well are not the ones with the best processes. They're the ones that have already built a culture of directness, where "we're off track" is a conversation that happens early, not late, and where the instinct is to fix the problem rather than manage the narrative.
If your CS team is in the habit of constructing end-of-year business cases out of retrospective data rather than tracking against agreed outcomes in real time, that habit will need to change before outcome-based contracts can work.
Not every customer, not every deal
It's worth being clear: outcome-based contracting is not universally appropriate. The overhead (the measurement infrastructure, the pre-sale scoping, the legal complexity, the cultural lift) is significant. For a high-volume, lower-touch book of business, it probably doesn't make sense.
Where it makes sense is in enterprise and strategic accounts where the deal size justifies the investment, where the customer is sophisticated enough to engage seriously with measurement, and where you have enough control over the delivery conditions to make the promise credible.
And, critically, where you genuinely believe you can deliver. Because the thing about outcome-based contracts is that they don't let you hide. Either the outcome materialised or it didn't, and the contract is very clear about which one it is.
That clarity can feel frightening. It's also, in the long run, the kind of clarity that distinguishes vendors who are genuinely transformative from those who just say they are.
The short version
Outcome-based contracts push risk back to the vendor and accountability onto the CS team. They require CS to be involved in pre-sale scoping, to own a measurement methodology from day one, and to have honest conversations when the trajectory is wrong.
The process work is concrete: a scoping framework, a measurement infrastructure, a risk escalation protocol. The cultural work is harder: building a CS team that's comfortable with real accountability rather than the appearance of it.
Not every deal belongs here. But in enterprise accounts, the direction of travel is clear. Getting ready before it becomes urgent is the CS ops problem worth solving now.
Where Pivotal Path comes in
Outcome-based contracting changes the CS motion from intake to renewal. We help CS leaders build the operational foundations (scoping frameworks, measurement infrastructure, escalation protocols) before the first outcome-based deal closes. If you're starting to see this in your pipeline, it's worth a conversation.
Working on this in your business?
We help UK SMEs and scale-ups turn this kind of thinking into action.
Read next
Making the CS Case to the CFO: What Finance Leaders Actually Need to Hear
The CS Budget Conversation Every Leader Dreads
CSM compensation: what to incentivise and what not to
The churn postmortem: what most CS teams don't learn from lost accounts
When Sales and CS share the same customer: the commercial ownership problem
