Outcome as a Service: Why Software Delivery Should End in a Business Number
Outcome as a Service is a way of building and operating software where the engagement starts with a measurable business problem, ships as a focused system, and continues—when appropriate—against the business number it was meant to improve.
The project is complete. The software works. The acceptance criteria passed. The team attended the handover. The final invoice was paid.
Three months later, the business number that justified the project has not moved.
Nobody necessarily failed to do what they promised. The software team delivered the software. The client received the software. The contract ended exactly where it said it would.
The problem is that the contract and the business were working towards different finish lines.
A software project can be complete while the business problem remains fully employed.
I think we need a better delivery model - We call it Outcome as a Service.
Software delivery usually ends too early
Most software engagements are organised around outputs:
- features completed;
- integrations connected;
- screens approved;
- tests passed;
- documentation delivered;
- and software launched.
These things matter. Bad software does not become valuable because somebody attached a business metric to the proposal.
But working software is still an intermediate result.
The reason a company funds a reconciliation system is not to possess a reconciliation system. It wants to close its books faster, reduce manual checking, or handle more volume without proportionally increasing the finance team.
The reason it funds a support agent is not to produce automated replies. It wants customers to get their problems resolved faster and at a sustainable cost.
The reason it funds a sales system is not to create another dashboard. It wants opportunities to move without relying on every salesperson remembering every next step.
The software is the mechanism.
It is not the final outcome.
The formal project-management world has recognised this distinction for years through benefits-realisation management. Project outputs are expected to create operational outcomes, which can then produce measurable benefits. Those benefits frequently need to be managed after the project itself has ended. PMI describes this distinction in its work on benefits realisation and project success.
Yet many software engagements still stop at the output.
That creates a responsibility gap.
The responsibility gap begins at handover
At handover, the software team can reasonably say:
The system does what we agreed it would do.
The client can also reasonably ask:
Then why has the problem not improved?
Between those two statements sit all the things that were never clearly assigned:
- Who makes sure the team actually uses the new workflow?
- Who watches the exceptions the system cannot handle?
- Who notices that one integration is producing incomplete data?
- Who changes the business rules when reality contradicts the original specification?
- Who measures whether the operating number is improving?
- Who decides what to change when it is not?
A handover transfers software.
It does not automatically transfer an operating system for producing value.
Sometimes the client has the people, process, and technical capacity to take over from that point. A clean handover is entirely appropriate.
Sometimes it does not.
In those cases, the project has delivered a new responsibility to a team that was already struggling with the old one.
What Outcome as a Service means
The phrase “Outcome as a Service” is increasingly used to describe pay-for-performance software, transaction-based pricing, or AI systems that complete work rather than merely providing tools. Those are useful developments, but I think the category needs a more careful definition.
Here is mine:
Outcome as a Service is a way of building and operating software where the engagement starts with a measurable business problem, ships as a focused system, and continues—when appropriate—against the business number it was meant to improve.
There are three layers inside that definition.
| Layer | What it asks | Example |
|---|---|---|
| System delivered | What can the software reliably do? | Read an invoice, retrieve the matching purchase order, flag a mismatch, and route it with context |
| Operating change | What changes in the way work happens? | Fewer manual touches, shorter queues, faster exception resolution |
| Business result influenced | Which number should improve as a consequence? | Lower cost per completed reconciliation or a shorter close cycle |
These layers should not be collapsed into one claim.
A provider can be directly accountable for whether the system works.
The provider and client may share responsibility for whether the workflow changes.
The final commercial result may also depend on adoption, leadership, data quality, market conditions, pricing, regulation, and decisions outside the provider’s control.
Outcome as a Service does not erase those boundaries.
It makes them visible.
A business number is a compass, not a warranty
Organising delivery around a business number does not mean promising guaranteed revenue, savings, or return on investment.
That would often be dishonest.
A sales system cannot guarantee that the offer is competitive.
A hiring system cannot guarantee that candidates will accept weak compensation.
A forecasting tool cannot repair inconsistent source data.
A support agent cannot protect retention if the underlying product keeps failing.
The provider should not claim control over variables it does not control.
But uncertainty is not an excuse to ignore measurement altogether.
The business number should act as a compass.
It should shape:
- what gets built first;
- which actions the system is allowed to take;
- which exceptions receive human attention;
- what gets measured after launch;
- and which improvements matter enough to enter the roadmap.
Without that compass, a project can accumulate features while moving further away from the original reason it was funded.
Start with the number before discussing the feature list
A useful software conversation should begin with a small set of operating questions.
What is happening today?
Not the strategy-deck version. The real workflow.
Who receives the input? What do they check? Which systems do they open? Where do they wait? What gets copied manually? Which cases are sent to someone else?
What is the unit of work?
A lead contacted. An invoice reconciled. A candidate moved to the next decision. A support case resolved. A document reviewed.
Without a clear unit, measurement becomes vague.
What does the workflow cost now?
The cost may appear as:
- staff time;
- delay;
- missed capacity;
- rework;
- error;
- abandoned demand;
- or senior people being pulled into routine cases.
The number does not need to be perfect on day one. It does need to be defined well enough to compare before and after.
Which part can the system own completely?
A feature may complete one step while leaving the rest of the job untouched.
Generating a reply is not resolving a support case.
Extracting invoice fields is not completing reconciliation.
Scoring a lead is not ensuring the right next action happens.
The strongest first scope is usually a complete, bounded loop. Large enough to change the work. Small enough to measure and control.
What happens when the normal path breaks?
Exceptions are not an implementation detail.
They determine whether the system remains useful in real operations.
A serious design needs to answer:
- What can the system refuse?
- What requires approval?
- Where does an exception go?
- What context travels with it?
- Who owns it next?
- How does the resolution improve future handling?
Who owns the number after launch?
A metric without an owner becomes dashboard furniture.
Someone must review it, investigate movement, and decide what changes next.
That owner may sit inside the client organisation. It may be a shared operating responsibility. In some engagements, the software provider may remain responsible for monitoring and improving the system.
What matters is that the answer is explicit.
The work after launch may be part of the product
The first live version of a system reveals things no planning document can fully predict.
Users behave differently from the expected workflow.
Source data contains inconsistencies.
Business rules conflict.
An unusual exception becomes common.
A model performs well on one category and poorly on another.
The cost of one action grows faster than expected.
This does not always mean the initial build was poor. It means the system has entered reality.
For stable, deterministic software with a capable internal owner, a conventional handover may be enough.
For systems whose value depends on changing data, model behaviour, exception patterns, adoption, or ongoing workflow redesign, post-launch operation may be part of the actual product.
That operation can include:
- monitoring quality and cost;
- reviewing exceptions;
- maintaining integrations;
- adjusting thresholds and permissions;
- improving weak parts of the workflow;
- and checking whether the operating number is still moving in the intended direction.
AI capabilities, costs, regulations, and recommended practices can also change quickly. A system designed once and never reviewed may gradually stop fitting the environment around it. OLN Labs discusses these limitations and the need to verify changing information in its disclaimer.
The build creates the system.
Operation helps the system continue producing value.
Outcome as a Service is not just a pricing model
Outcome-led work can use several commercial structures.
A planning sprint may have a fixed fee.
A focused build may be billed against delivery milestones.
Post-launch operation may use a monthly managed engagement.
In selected situations, compensation may include a transaction fee, revenue share, or another risk-sharing structure.
OLN Labs currently uses a combination of fixed planning work, milestone-based focused builds, optional managed support, and selective risk-shared engagements. You can read more about how OLN Labs works here.
But changing the invoice structure alone does not create Outcome as a Service.
A performance fee attached to a badly defined metric creates arguments, not alignment.
The more important change is responsibility:
- the business problem is defined before the system;
- the operating mechanism is visible;
- ownership survives launch;
- exceptions are part of the design;
- and the number continues to guide improvement.
Commercial alignment should support that model.
It cannot substitute for it.
When this model is the wrong fit
Outcome as a Service is not appropriate for every software project.
It is usually a weak fit when:
- the desired outcome cannot be measured meaningfully;
- the workflow happens too rarely to justify a custom system;
- the process changes every week and has no stable owner;
- the required data is inaccessible or unreliable;
- the result depends almost entirely on external market behaviour;
- the company is unwilling to change how the work happens;
- or an existing product already solves the problem well enough.
In those situations, the right answer may be a process change, an off-the-shelf tool, a small integration, or no software at all.
Not building is also an outcome.
A better finish line
Software delivery should not promise control over a business result that no provider can fully control.
But it should be organised so that the business result is impossible to ignore.
That means starting with the number, designing the operating loop, assigning responsibility, shipping the smallest valuable system, and deciding who will keep improving it after launch.
The final pull request is not the business finish line.
Neither is the handover meeting.
The finish line is the point where a useful system has changed the way work happens—and the organisation can see that change in a number it already cares about.
That is what I mean by Outcome as a Service.
At OLN Labs, we start with the work, build around one high-value operating problem, and can stay involved after launch to run and improve the system against agreed business numbers.
Frequently asked questions
What is Outcome as a Service?
Outcome as a Service is a delivery and operating model that begins with a measurable business problem, builds a focused system around it, and continues measuring and improving that system when ongoing operation is required.
Is Outcome as a Service the same as outcome-based pricing?
No. Outcome-based pricing can support the model, but the defining feature is responsibility for the operating loop and measurement. An engagement may still use fixed fees, milestones, or managed support.
Does Outcome as a Service guarantee ROI?
No. Business results can depend on adoption, data quality, leadership decisions, market conditions, regulation, and other variables outside the provider’s control.
Which metrics should an outcome-led software project track?
Track three layers: system performance, operating change, and the commercial result influenced. This prevents a working feature from being mistaken for a completed business outcome.
When should a software provider remain involved after launch?
Ongoing involvement is useful when value depends on model monitoring, changing business rules, exception management, integrations, adoption, or continuous workflow improvement.
If there is a recurring workflow in your business whose delay, cost, capacity, or error rate is visible, schedule a call with us.
Bring the workflow and the number.
We will help you decide whether the right first step is to change the process, buy an existing tool, or build something focused around it.
