Applied AI in a service business: what to automate first, and what to never automate

Most AI conversations inside a service business stall in the same place. Somebody demonstrates a chatbot, everybody agrees it is impressive, and nobody can say which process it belongs to or what it would replace. The demonstration was of a capability. What a business needs is a decision about a workflow.

Applied AI means the second thing: a model doing a named job inside a process that already exists, with a defined input, a defined output, and somebody accountable for the result. Everything below assumes that framing, because the other one has no failure mode you can measure and therefore no success you can claim.

The line that decides everything: judgment or throughput

Sort every candidate process into one of two piles. In the first, the work is hard because there is a great deal of it and it is unstructured — reading, sorting, summarising, drafting, translating, matching. In the second, the work is hard because it requires a judgment somebody has to own — pricing, hiring, credit, discipline, diagnosis, anything with a legal consequence.

Language models are extraordinarily good at the first pile and structurally unsuited to the second, not because they reason badly but because they cannot be audited the way an accountable decision has to be. Start with throughput. The return is immediate, the failure mode is visible, and nobody has to defend it to a regulator.

The three processes worth doing first

1. Reading unstructured customer text at volume

Reviews, emails, support tickets, form submissions, the comments on your own social posts. Every service business generates more of this than anybody reads, and the value is not in any single item — it is in the pattern across hundreds, which is precisely what a human reader cannot hold in their head and a model can process in seconds.

This is the highest-return first project in almost every service business we look at, and it is rarely the one being considered.

2. Drafting anything that a person will approve

Review replies, quote follow-ups, appointment reminders, the summary of a site visit. The model produces a draft; a person reads it and sends, edits, or discards. The approval step is not a training-wheel to be removed later — it is the control that makes the whole thing safe, and it is what keeps the output sounding like your business.

3. The recurring summary nobody has time to write

The weekly operations note, the monthly rollup, the handover document. These are skipped in every busy business and are exactly where institutional memory leaks out. A model given the underlying material writes a serviceable version in a minute, and a serviceable version that exists beats an excellent one that does not.

What to never automate

• Anything that produces a number you will act on. Counts, frequencies, percentages, scores. A model asked how often something occurs will produce a confident figure that is not a count. Compute numbers in code, over what the model extracted.
• Any decision about an individual person. Hiring, firing, credit, pricing that differs by customer. Beyond the legal exposure, these are the decisions you will one day have to explain, and "the system said so" is not an explanation.
• Anything you cannot trace back to its input. If you cannot point at the source material behind an output, you have bought a confident opinion, not analysis.
• The last mile of a relationship. The apology, the difficult phone call, the negotiation. Customers can tell, and the cost of being caught outsourcing sincerity is larger than the time saved.

The audit test

Before any AI-assisted output is allowed to influence a decision, ask one question: can I get from this sentence back to the thing it came from? Not in principle — in practice, in under a minute, with a link or a document and a date.

An output that survives this test can be argued with, which is the only property that makes it useful in a room where people disagree. An output that does not is a very articulate guess. The distinction has nothing to do with model quality and everything to do with how the process around it was built.

A sequence for a ten-to-fifty person firm

1. Pick one process from the throughput pile that somebody currently does badly because they are busy, not because it is hard.
2. Write down what good looks like before you start — a paragraph, in plain words. This becomes the acceptance test and prevents the pilot from being judged on how impressive it feels.
3. Keep the human approval step for the first hundred outputs, and keep the ones that were edited. The edits are the specification for the next iteration.
4. Move the counting into code. The moment the output starts carrying numbers, they must stop coming from the model.
5. Measure the process, not the tool. Fewer hours, faster response, fewer recurring complaints. If none of those moved, the pilot failed and that is a useful result.