Article · Buying Decisions
Service as software: what it is and how it differs from SaaS
Service as software is a model where you buy the work done, not the tool to do it. The software stops being a licence your team operates and becomes the workforce that runs the operation in the background: agents that perform the task and a provider that maintains them. You contract the result (resolved cases, prepared files, a process running to agreed service levels) and the provider absorbs the technical cycle behind it. It is the inversion of the SaaS model, and it changes above all who does the work.
The inversion of the SaaS model
In the classic SaaS model, you buy access to a tool and your team does the work with it. The bill measures seats or consumption. The provider maintains the common product and you supply the users, configure the workflow, integrate your systems and remain responsible for running the operation. The software is a lever that multiplies your people’s work, but the work still belongs to your people.
Service as software turns that relationship around. The software is no longer the tool a person uses: it is the one doing the task. The bill moves toward the result rather than the seat. The provider does not hand you an application to operate. It operates the capability itself and is accountable for what it produces. What you buy is not the ability to do the work, but the work. This is the commercial thesis behind the Arkatai model, and I develop it as a buying decision in buy vs build enterprise AI.
| SaaS | Service as software | |
|---|---|---|
| What you buy | Access to a tool | The result of the work |
| Who does the work | Your team, with the software | The software, maintained by the provider |
| What the bill measures | Seats or consumption | Result or operating capacity |
| Who configures and integrates | The client | The provider |
| Who maintains the technical cycle | The client | The provider |
How it differs from BPO
Business process outsourcing (BPO) also sells you a result: you hand a process to a third party and it runs it with its people. The resemblance ends there. BPO scales with people: to do twice the work, it hires twice the people, and its economics follow hours and salaries. Service as software scales with software: the same system absorbs more volume without a proportional headcount, and the repeatable work is productised inside the platform.
The practical difference shows in the trace and in the improvement. A process run by software leaves a record of every decision (what it received, which rule it applied, what it did), which lets you audit it in a detail a manual process rarely offers. And the improvement runs on two levels. Patterns that repeat across clients strengthen the shared platform, and the metrics from every run (quality, cost, time, exceptions) continuously improve your specific process. In BPO, the knowledge lives in the people executing; when they turn over, part of the capacity leaves with them.
How it differs from consulting
A consultancy sells a project: an analysis, a design or an implementation with an end date. When it finishes, you receive deliverables and a pending decision: who operates and maintains what was built. The software, if there was any, is yours to operate, with the cost and risk that implies. Consulting is accountable for the quality of the work delivered, not for the operation still running the following month.
Service as software does not deliver a project someone then has to operate: it keeps the operation running as a recurring service. The test to tell one from the other is simple. If the provider retains and maintains a common platform, is accountable for a continuous service and turns each deployment’s patterns into improvements to the core, it is service as software. If every client receives an isolated project and every improvement requires rebuilding it, it is consulting under another name. I have developed this distinction, with the forward-deployed engineer at its centre, in what a forward-deployed engineer is and in in-house team, consultancy or forward-deployed engineers.
Who takes on the technical cycle, and why that changes everything
The underlying argument is not semantic. Many mid-market companies do not have a product and technology department able to maintain agents, evaluations, integrations and model changes at the current pace, and standing one up is a new function with its fixed cost and turnover risk. That technical cycle (testing new models, redoing evaluations, maintaining connectors, governing permissions and traces) never stops, because models change and the process changes.
Service as software exists because that cycle can live outside the client. The provider absorbs it: when a better or cheaper model appears, it evaluates and replaces it without the client having to touch anything, treating models as interchangeable components. The client keeps what is genuinely theirs (directing its data and its business decisions) and is spared building a technical workforce to operate the technology. The real trade-off is a dependence on the operator, which you should acknowledge and contract well: who owns what, how the service is measured and what you take with you if you leave. I cover those buying criteria in how to choose an AI agent provider, the price in AI agents implementation cost and the return in the ROI of AI in operations.
When service as software is the wrong answer
The model has a range where it fits, and outside that range it behaves badly, so it is worth saying where it ends. There are four situations where I would not recommend it, and none of them has to do with company size.
Without volume and repetition there is nothing to productise. A process that happens twenty times a year and never the same way gives the provider no material to turn into reusable capability. What they sell you will be a bespoke build with a service label, and you will pay for it as such.
When the process is your competitive difference. If what gets executed is precisely why your customers choose you, dependence on the operator stops being an operating cost and becomes a strategic decision. It can still pay off, but it is decided on another plane, and that plane is buy vs build for enterprise AI.
When there is no internal owner with authority over exceptions. The model needs someone in your house who decides what happens to the cases that leave the rails. Without that name, exceptions pile up, the service degrades and blame gets apportioned wrongly, because the provider cannot decide about your business for you. How that circuit is designed is in exception handling and human escalation.
When execution has to stay inside. Sometimes your sector’s regulation imposes it, sometimes a contract with a large customer does. It is a constraint on the perimeter rather than an opinion about the model, and it pays to spot it before you negotiate. And if on top of that the purchase has to be a one-off outlay instead of a recurring contract, the right comparison is in automation agency or managed operation.
That this specific work happens during the deployment does not mean you receive a bespoke codebase. The provider keeps the platform and productises within it whatever repeats, and you run the business. That is the substance of the custom phase, and the entry point to the whole set is AI agents for business.
Frequently Asked Questions
What is service as software?
A model where you buy the work performed rather than the tool to perform it. The software acts as the workforce that does the task and the provider maintains it, and you contract the result or the operating capacity. It inverts the SaaS model: instead of buying access and doing the work yourself, you buy the work done.
How does service as software differ from SaaS?
In SaaS you buy access to a tool and your team does the work with it, and the bill measures seats. In service as software the software does the work, the provider maintains the system and the bill moves toward the result. What changes above all is who executes and who takes on the technical maintenance.
Is it the same as outsourcing a process (BPO)?
No. BPO scales with people and its knowledge lives in whoever executes. Service as software scales with software, leaves a trace of every decision and productises the repeatable inside the platform. Both sell you a result, but the unit that grows is different: people versus software.
When is service as software the wrong choice?
When the process lacks the volume and repetition to be productised, when it is precisely what your customers choose you for and you want the capability in-house, when there is no internal owner with authority to decide on exceptions, and when regulation or a customer contract requires execution to stay inside your perimeter. None of the four depends on company size.
Can I bring the process back in-house later?
Yes, and it is worth agreeing how before you sign. At the end of the contract you receive the operating architecture specific to your process (rules, exceptions, controls, data contracts, evaluation criteria) along with the agreed export of data, results and traces. That saves you rediscovering the operation, which is the expensive part. It does not save you reimplementing it, because the provider’s platform does not travel with you.
Who maintains the technology in service as software?
The provider. It absorbs the full technical cycle: testing and replacing models, redoing evaluations, maintaining integrations and governing permissions and traces. The client directs its data and its business decisions and names a process owner, but does not need to build a technical department to operate the system.