Where AI actually pays off in a smaller business

A familiar situation: a business has bought licences for two or three AI tools. A handful of enthusiastic people use them daily. Everyone else tried it once. No process has changed, no cost has come down, and nobody can say what the spend has produced. Meanwhile the board has started asking about the AI strategy.

This is not a failure of the technology. It is what happens when tools are bought before a problem is chosen.

The four characteristics of a use case that works

Across the assessments we run, the automation projects that repay their cost tend to share the same shape:

1. High volume, low variance. The same category of task, many times a week. Twenty near-identical jobs a day is a far better candidate than one complicated job a month, however painful that job is.
2. A tolerable failure mode. When the system gets one wrong, someone notices before it reaches a customer or a ledger. Internal drafting qualifies. Automatically issuing credit notes does not.
3. An existing correct answer to learn from. Approved proposals, closed tickets, historic quotes, a policy library. Where you have a body of past work that was signed off, output quality improves dramatically.
4. A named owner who wants it. Someone whose week visibly improves. Automation with no internal beneficiary gets quietly abandoned within a month.

Notice what is absent from that list: novelty, customer visibility, and anything resembling a strategic narrative.

Where the returns usually actually are

Retrieval over your own documents

Most businesses hold their real operating knowledge in files nobody can search: contracts, specifications, manuals, historic tenders, policy documents. Making that corpus answerable in plain language (with citations back to the source file, so an answer can be verified) is consistently the highest-value, lowest-risk first project. It does not change any process, so nothing breaks, it just stops people spending twenty minutes finding a clause.

Drafting with mandatory human review

First-pass proposals, tender responses, scoping documents and questionnaire answers, generated from material you have already approved. The saving is not in the writing, which was never the slow part. It is in getting from a blank page to something worth editing.

Classification and routing of inbound work

Invoices, application forms, support tickets, inbound enquiries. Extracting the fields, categorising the item and routing it to the right queue is unglamorous and reliably worth doing. This is the category most likely to recover a genuine day a week.

Quality checking against a rulebook

Reviewing outbound documents for missing clauses, inconsistent figures or non-compliant language. It works because the rulebook already exists and the cost of a false positive is a two-minute human check.

Where the money tends to go missing

• Customer-facing chatbots, deployed early. High visibility, low tolerance for error, and they surface every inconsistency in your existing documentation. A reasonable phase-three project, a poor phase one.
• Platform-first purchases. Buying an "AI platform" before a use case is chosen produces a licence, a project manager and a search for problems to justify them.
• Pilots with no success criterion. If nobody wrote down what "good enough" meant before starting, the pilot will end in an argument about vibes and quietly lapse.
• Automating a process that should be deleted. Some workflows exist because of a system limitation resolved four years ago. Automating them makes a bad process faster.

Governance is not optional, and it is not long

Before anything touches real data, two documents need to exist. The first is a short acceptable-use policy: which tools may receive which categories of data, where a human must review output, and what your obligations are to clients whose information is involved, a genuine question under UK GDPR and the Australian Privacy Act, and one your enterprise clients will eventually ask about in writing.

The second is an evaluation standard: for each use case, what accuracy is acceptable, what failure modes are unacceptable at any rate, and what the cost per task is. Both fit on a few pages. Skipping them does not save time, it defers a harder conversation to a worse moment.

A reasonable sequence

1. Map where the hours actually go, by following two or three high-volume processes end to end and talking to the people doing them.
2. Pick one use case that meets all four characteristics above. One.
3. Define what good enough means, in writing, before building anything.
4. Test on your own real cases and measure against that standard.
5. Roll out with a named owner, and retire the manual process it replaced, otherwise you now run both.
6. Only then consider the second use case.

This is slower than buying a platform and considerably faster than buying three of them in succession.