AI automation for business: where to start and where to stop
Demos are easy, production is hard. How to choose which process to automate, why the human-handoff rate is the headline metric, and where the cost actually sits.
In AI projects the distance between a demo and production is longer than in any other kind of software. In a demo it is enough for the model to answer ten questions correctly. In production what matters is how many of a thousand questions it answers wrongly but convincingly.
This article is about choosing which work to automate.
Four properties of a good candidate
Tick four boxes before handing a process to automation.
1 · High repetition. Building a system for a request that arrives three times a month never earns back the setup. Three hundred times a month and the maths changes.
2 · The correct answer is written down somewhere. Answers grounded in the model’s own “knowledge” are risky in production. If the source is your document — a price list, a procedure, a policy — the model can speak from it. That is the reason retrieval-augmented generation exists.
3 · A wrong answer is recoverable. A wrong shipping-status answer can be corrected. A wrong dosage answer cannot. The error tolerance of the domain sets the limit of automation.
4 · You can measure the outcome. Do not ship a system whose accuracy you cannot measure. “It looks good” is not a measurement.
If all four are not met, the project may be technically feasible but is commercially a loss.
The three applications that most often pay
Answering repeated questions. Price range, process, delivery, returns, opening hours. Most support load is this type, and the answers are already written.
Extracting fields from unstructured data. Reading specific values out of an incoming email, invoice or contract and writing them into a system. The model is not being creative here, so the error rate is low and verification is easy.
Conversation and call analysis. Scoring sales conversations, classifying objections, checking whether a next step was agreed. Because this is work nobody was doing by hand, the cost of a wrong answer is low — nobody was reading them anyway.
Getting RAG right
Retrieval-augmented generation looks simple: chunk the documents, embed them, retrieve the closest matches, hand them to the model. Where it stalls in production is predictable:
Semantic search alone is not enough. On exact facts like prices, the model tends to retrieve a semantically close but wrong line. Combine it with keyword search and rerank the result.
Chunk boundaries matter. Chunking that splits a table in half makes the answer impossible. Splitting that respects document structure makes more difference than the choice of model.
Cite the source. Let the model answer only from retrieved passages, and refuse when there is no grounding. A system that can say “I don’t know” is incomparably more valuable than one that invents convincingly.
Knowledge bases go stale. If the price list changes and the vector store does not, the system states the old price with full confidence. Build the update path from day one.
Handoff is not a number to hide
Every automation needs a confidence threshold, and everything below it must go to a person.
The handoff rate is not a sign of failure — it is the headline metric. A system running at 30% handoff that never answers wrongly beats one at 0% handoff that misspeaks five times a week.
Handoff should be invisible to the user: the conversation history transfers to the human, so nobody has to explain themselves twice.
Where the cost actually sits
Token cost is usually the smallest line. The real cost is here:
| Item | Note |
|---|---|
| Preparing the knowledge base | The largest and most skipped item |
| The evaluation set | Human-labelled question-answer pairs |
| The update pipeline | Refreshing vectors when documents change |
| Human review queue | Someone to handle handed-off cases |
| Model calls | Usually a small share of the total |
The evaluation set matters most. When the model or the prompt changes, that set tells you whether accuracy dropped. Without it, every change is a gamble.
A practical starting sequence
- Pull the 20 most repeated questions from your support records.
- Collect the documents where those answers are written.
- Build a 50-question evaluation set by hand.
- Start narrow — one topic, one channel.
- Keep the confidence threshold high; let the handoff rate start high.
- Lower the threshold gradually as accuracy on the evaluation set stabilises.
The most common mistake is skipping step four and automating everything at once. A system that starts narrow grows; one that starts broad loses trust and gets switched off.
