For twenty years, software helped you do the work. Now it can do the work. That changes what a software company is — and what buying one means.
SaaS was built on a clean division of labour. The vendor shipped the tool; you did the work. However good the software got, the contract never moved: we provide capability, you provide labour, and the outcome — the settled claim, the closed case, the happy customer — was always yours to deliver.
Every pricing model in the industry reflects it: per seat, per user, per month. You're paying for access to a tool, priced by how many of your people pick it up.
That contract made sense because software couldn't do the work. It could record it, route it, report on it — but a claim still needed a person to read the file, weigh the evidence, make the call and talk to the customer. The per-seat price was, in effect, a headcount tax on the vendor's behalf: the better your software, the more people you could afford to point at the problem.
AI's real shift in claims isn't better features. It's that software can now perform meaningful parts of the operation — read the unstructured file, assemble the evidence, propose the reserve, draft the communication, settle the routine case under guard-rails. The boundary between "tool" and "worker" — the boundary the entire SaaS contract was built on — has dissolved.
When that boundary goes, software companies split into two kinds. One kind keeps selling tools: increasingly capable, increasingly commoditised, still leaving the outcome entirely with you. The other kind starts taking responsibility for outcomes — not "here's software that helps your team settle claims" but "claims get settled, and here's the evidence." That second kind is what we'd call service as software: the operating model, the expertise and the accountability delivered through the platform rather than around it.
This is not the old BPO trade of "give us the work, lose the visibility." That trade was forced by a technical limitation — if the work happened inside someone else's building on someone else's systems, you got a monthly bordereau and a quarterly meeting, because that was all the wiring could carry. The platform removes the limitation. It is what makes responsibility transferable without control transferring with it: every decision visible, live, with the audit trail attached. You hand over effort, not oversight.
The traditional choice was binary and brutal. Run claims yourself — buy the tools, hire the people, own the whole cost line. Or outsource the lot, and hand your biggest cost line to a black box. A door: you were on one side of it or the other, and walking through it was a multi-year decision with a painful reverse.
Service as software turns the door into a dial. If the same platform can support your team or perform the work itself, then how much responsibility the vendor takes stops being an identity and becomes a setting. Start with the software running your operation, calibrated on your book so the models are yours rather than generic. Add the vendor's specialists alongside your team for the complex and disputed work. Call on full capacity when a storm hits, a backlog builds or a new line launches. Hand over the whole operation when — and only when — the track record has earned it. Same platform underneath at every setting. What moves is the responsibility line.
And it moves in both directions. A dial you can only turn one way is a door with extra steps. If a customer builds out their own team and wants to take work back in-house, the platform stays and the service layer thins — which is the only version of this that a buyer should be willing to sign.
This is also, incidentally, how trust actually builds between organisations: incrementally, on evidence, with an exit. The dial matches the commercial model to the trust curve, instead of demanding a leap of faith on day one and calling it a partnership.
Responsibility becomes a dial, not a door.
Three practical consequences, whoever you end up buying from.
Stop asking "build vs buy vs outsource." It was a reasonable question when the three were genuinely different commitments with different systems, different contracts and different exits. It's the wrong question now, and asking it forces a decision at the moment you have the least information — before you've seen the vendor perform. The better question is narrower and answerable: where should the responsibility line sit today, and what specifically would justify moving it? If you can name the evidence that would move it — loss ratio on a cohort, cycle time on a peril, complaint volumes holding through a surge — you have a procurement process instead of a leap.
Pricing will follow responsibility, and per-seat will look strange quite quickly. Expect a spectrum rather than a single model: platform subscription where the vendor supplies capability, per-claim where it supplies capacity, and outcome-linked components where it genuinely owns the result. Watch for the tell — a vendor that wants outcome-linked pricing but won't accept an outcome-linked metric is selling you a tool with a service-shaped invoice. The corollary matters too: paying for outcomes only makes sense when the vendor can actually own them, so if the AI is a thin layer over your own people doing the work, per-seat was the honest price all along.
Demand the evidence layer, and test it before you need it. A vendor asking for responsibility must show its working: live data rather than monthly files, decision-level audit trails rather than summary reporting, AI whose reasoning you can interrogate and overrule rather than a score with no provenance. If you can't see how the work is done, you haven't delegated it — you've lost it. The test is not whether the dashboard looks good in a demo. It's whether you can pull a single claim at random, six months in, and reconstruct every decision on it and who or what made them.
There's a version of this argument that faces inward, and it's worth saying out loud because it's the same argument.
If software does the routine work, what's left for the humans is the part that was always the actual craft: the complex loss, the disputed liability, the vulnerable customer, the judgment call the guard-rails are deliberately built to escalate. That changes what a claims job is, and it changes who you need to hire. The old TPA model treated handlers as capacity — measured by volume, priced by the hour, managed to a caseload. Service as software treats them as expertise, and puts them shoulder to shoulder with the engineers building the system they work in, because the feedback loop between the two is the product.
So the external story and the internal one are the same story from two sides. Externally: responsibility is a dial. Internally: one team, claims experts and engineers, building the thing that makes the dial possible. A company can't credibly offer the first without organising itself around the second, which is a reasonable question to ask any vendor making this pitch — including us.
We didn't add a service arm to a software company, and we didn't bolt software onto a TPA. Both of those are retrofits, and both are visible from the outside within about one meeting. ADJST is built as service as software from the first line of code: one platform, one data plane, one AI, and four service tiers on top of it — Calibrated SaaS, Embedded Experts, TPA On-Demand, Full TPA. Same system underneath all four. What changes is only how much of the operation we take on.
We're honest about where we are: the platform's first release is ahead of us, not behind us, and the service tiers follow it in sequence. But the architecture was decided on day one, and this is the decision it was made for. Where the responsibility line sits is the customer's choice. That it can sit anywhere is the point.
ADJST is building the AI-native claims platform — and the services to run it, from Calibrated SaaS to Full TPA.