Outcome as a Service: A Service Is a Job, Not a Task

Outcome as a service is a business model where the customer pays for a result instead of a tool, a seat, or hours of effort. The provider does the work and carries the responsibility for getting it right. That much every definition agrees on. What the definitions leave out is the unit being sold. A result that happens once is a task. A result the customer needs to stay true, every week, for every location and every new hire, is a job. The job is the unit software companies will sell next.

Most writing on outcome as a service treats it as a contract or pricing question: what do you charge for, and who pays when it fails. Those are real questions. But they assume the outcome is a single event you can count, like a wall built or a ticket closed. Most of what a software company's customers need is not an event. It is a state that has to be held: every location compliant, every certificate current, every new hire through onboarding.

Holding a state takes the product, the customer's data, and the customer relationship, all at once. The company that already sells the software has all three. That is the argument of this post: outcome as a service is not only an opportunity for new companies replacing labor. It is the natural next product for the companies that already own the software the work runs on.

What outcome as a service means today

The idea is older than AI. Rolls-Royce's TotalCare program is the textbook case. As Rolls-Royce describes it, "TotalCare is charged on a fixed $ per flying hour basis, so we are only rewarded for engines that perform." The airline does not buy maintenance events. It buys engines that keep flying, and the program "transfers the management of associated risks to Rolls-Royce."

The same shape shows up in robotics and construction. Foundamental's essay on OaaS puts it plainly: "Outcome-as-a-service is a business model by which you're not selling a product." Its example is a bricklaying robot company that positions itself as a subcontractor delivering completed walls, so the client buys the wall, not the robot.

AI made the model relevant to software. Sequoia's Sonya Huang and Pat Grady wrote in 2024 that "the AI transition is service-as-a-software," and drew the contrast in one line: "Cloud companies sold software ($ / seat). AI companies sell work ($ / outcome)." Gartner now has its own label for it. ITPro reports that Gartner coined "outcome as agentic solution" (OaAS), where enterprises contract for outcomes instead of buying access to tools. Under SaaS, "the customer is responsible for purchasing a tool and using it to achieve results." Under OaAS, the vendor carries the execution.

So the common definition has three parts:

• The customer buys a result, not access.
• The provider does the work.
• The provider carries the risk when the result does not arrive.

All three are right. None of them say what the result looks like when it is not a one-time event.

Tasks, automations, seats, and jobs

It helps to put the options side by side. Each one answers a different question about what the customer is buying.

A task is "send the overdue training reminder." A job is "keep every location compliant." The task ends when the reminder is sent. The job is still open, because the point was never the reminder. The point was the compliance.

Reports, reminders, enrollments, escalations and fixes are all things done in service of a job. None of them are the job. That distinction matters for anyone trying to sell outcomes, because a task is easy to count and hard to value, while a job is the thing the customer actually wanted when they bought the software in the first place.

The finance world is reaching the same distinction from a different direction. Cashflo's piece on finance outcomes as a service frames the shift as moving from asking "Did we process this?" to asking "Is the outcome correct?" The first question is about a task. The second is about a job.

What a job looks like

Take an illustrative example. Lessonfield is a learning management system. One of its customers, Pellmark Training, runs locations in Dallas and Denver, and every staff member at every location needs current safety training.

Sold as software, Lessonfield gives Pellmark a course catalog, enrollment screens, and a compliance report. Maya, the operations lead at Pellmark, logs in, reads the report, notices Dallas has slipped, enrolls the three new hires, and chases their managers. The software is excellent. Maya still does the job.

Sold as a service, the job is "keep every Pellmark location compliant." It has a state, say 11 of 12 locations compliant. When a new hire starts in Dallas, the state slips, and the AI acts: it enrolls the new hire through Lessonfield's own tools, reminds them before the deadline, and loops in their manager on Slack if they fall behind. When Dallas is back to compliant, the job is not finished. It is holding.

A week of that job reads like a log, not a report:

• Monday: three new hires in Dallas enrolled.
• Wednesday: one hire still not started, manager looped in on Slack.
• Thursday: Dallas back to compliant.

Nothing in that log is new technology. The difference is who owns it. In the first version, Maya owns the job and the software helps. In the second, the job is owned for her, and she sees the state.

Why the software vendor is best placed to own the job

Most writing on service as software is aimed at AI-native startups going after labor budgets. Foundation Capital frames the prize as "the $4.6T enterprises spend on salaries and services," against roughly $200B for SaaS. That is a fair way to size the market. But the same essay notes that an outcome "is ultimately a function of the customer's product, not just your software." Delivering a result depends on the systems it runs through.

That observation points somewhere the startup framing does not. To hold a job like "keep every location compliant," you need three things:

1. The product. The enrollments, the course records, the completion data. The work happens inside the software, so whoever does the work needs to act in it, as the customer, with the customer's permissions.
2. The data. Who the new hires are, which locations exist, what counts as compliant. That lives in the vendor's database and in the vendor's systems around it, like the CRM and support history.
3. The customer. The relationship, the contract, the billing, and the trust to act on someone's behalf.

A startup building outcome as a service from scratch has to acquire all three, usually by integrating with someone else's product from the outside. A general AI assistant reaching in through an API has some of the product and none of the relationship. The software vendor already has all three. It is the only party that does not have to ask anyone's permission to deliver the job.

There is a second reason. Gartner's own framing, as ITPro summarizes it, describes the vendor taking on execution and accountability for results, with success measured by things like invoices processed or months closed. Accountability needs visibility. The vendor can see whether Dallas is compliant because Dallas's training records live in its product. An outsider has to infer it.

This is also why the jobs a vendor delivers can be priced. Rolls-Royce could charge per flying hour because it could see every engine. A software vendor that owns a job can charge for the job, usually as a subscription, because it can see the state it is holding. We wrote more about that delivery problem in outcome-based pricing for software companies.

Where outcome as a service is harder than it sounds

It is fair to concede the hard parts.

• Not every outcome belongs to the vendor. Foundation Capital's point cuts both ways. If a result depends mostly on the customer's own operations, the vendor cannot guarantee it, and should not price as if it can.
• Variable results are hard to price per result. The same Foundation Capital essay notes that pricing per result works poorly when results vary widely across customers, which is why many AI tools still price by task or usage. A subscription for the job avoids this: the customer pays for the job being held, not for each event inside it.
• Adoption is early. ITPro reports that few enterprises have run OaAS at scale and that Gartner expects broader mainstream adoption after 2028.

None of this argues against the model. It argues for being precise about which jobs to sell first: ones where the state lives inside your product and you can see it slip.

How to pick the first job to sell

If you run a software company and want to sell outcomes, start with what your customers already ask your support or customer success team to do for them. Then filter:

• Does the work happen inside your product? If it does, you can act on it as the customer.
• Is there a state you can see? Compliant or not, onboarded or not, current or expired. If you cannot see the state, you cannot hold it.
• Does it slip on its own? New hires start, certificates expire, locations open. A job is worth owning when it keeps coming undone.
• Would the customer pay to stop thinking about it? That is the price of the job, and it is yours to set.

The answer is usually not the most impressive AI feature on your roadmap. It is the boring job your best customers already do by hand every week. We built services in Aimdoc around exactly this unit, and wrote about why in too many MCP tools: why we built services.

FAQ

What is outcome as a service?

Outcome as a service is a business model where a provider sells a result instead of a product, seat, or hours of effort, and takes responsibility for delivering it. Gartner calls the AI version of it "outcome as agentic solution."

How is outcome as a service different from SaaS?

With SaaS, the customer buys access to a tool and does the work. With outcome as a service, the provider does the work and is accountable for the result.

What is the difference between a task and a job?

A task is done once and then it is over. A job is a state the provider keeps true for each customer over time, like keeping every location compliant, and it acts whenever that state slips.

How should a software company price a job?

Usually as a subscription for the job, set by the vendor and charged to its own customers. The price reflects the job being held, not each reminder or enrollment inside it.

Your customers want outcomes, and you already own the product, the data, and the relationship they depend on. Aimdoc connects securely to your product and your systems, then delivers the work your customers need: metered, monitored and cost controlled. See how services work and how to sell them through your own Stripe account, or start free.