Skip to content

Sell the work, keep the judgement

Investors now say the next big software companies will sell the work and not the tool. The split they use, between intelligence work and judgement work, is useful. Where I part ways: the line between the two is drawn by the system around the model and by law, and what compounds is not data pooled across customers.

Written by

Essay3 min read

Earlier this month Julien Bek at Sequoia published Services: The New Software. His claim: if you sell the tool, you race against the next model; if you sell the work, every improvement in the model makes your service better. The idea has an earlier source. Joanne Chen and Jaya Gupta at Foundation Capital described it in 2024 as service as software, and the term is theirs.

I read it as one of the companies that argument is about. Everyone quoted here sells something, as I do, so read them with that in mind.

What I take

Bek splits every profession into two kinds of work. Intelligence work is the part governed by rules, however complex: apply the protocol, assemble, write up. Judgement work is the part that rests on experience: what matters here, what do we do now. I find that split useful, and I use it.

I also take his conclusion. Whoever sells the outcome answers for it. That is a different relationship from selling a licence, and it is where a company shows whether it means what it says.

Where the line really runs

Bek lets the line move with how capable the models get. I think two other things draw it.

The first is the system around the model. Work is only sellable as an outcome when it can be checked. That is a property of the surrounding system, not of the model: designated sources, a version in force, a source that can be opened, a gap that is declared. Inora does the intelligence work: it finds the protocol the organisation designated, puts the answer together with its source, and writes the report under the organisation’s own headings.

The second is law and design. A professional keeps the judgement in care because Inora is built that way, and because supporting a professional is a different thing from diagnosing or choosing treatment. That line keeps Inora outside the rules for medical devices, and it holds however good the model gets.

So I do not accept that today’s judgement will be tomorrow’s intelligence. Bek writes that systems will gather data about what good judgement looks like and converge towards it. In care, that deliberately stops at the decision about this one person.

What compounds

His argument for convergence is data pooled across customers. Our sovereignty rules that out, and so does the GDPR. What an organisation puts into Inora trains no model. If anything compounds for us, it is the system around the model and the craft of implementing it. That is slower, and I think it is also sturdier.

A question for outcome pricing

Sierra argues for being paid per resolved case, and Decagon admits that the unit of an outcome is hard to pin down. I see a problem neither raises. Pay per resolution rewards confident closure and punishes the answer “not in our sources” and the handover to a colleague. Ask any vendor paid per outcome what it earns when its agent says it does not know.

What it is for

In care the value is not the wage you no longer pay. There are not enough people to hire in the first place. The value is time and certainty for those who are there. I name no price here, because we have not set one, and I use no market figures.

Do you work in care and use Inora? Sign-in and help go through your own organisation: your team’s project lead and ambassadors can help you.