Almost every conversation about AI adoption starts with “which model should we use”. It is the safest question: it has a neat answer you can take to the board. The trouble is that choosing a model is the last decision in a project, not the first. Start by working out which work a person will stop doing by hand — and how you will see that in the numbers.

Start with processes, not technology

Take the three or four processes that consume the most person-hours and break each into steps. Look for steps where someone moves data between systems, re-reads a document to find a single paragraph, or makes a decision by a clear rule. Those are your automation candidates: they have an input, an output and a criterion for being right.

Leave people the steps where someone negotiates, takes responsibility or handles exceptions. Trying to automate exactly those is the most common reason a pilot looks impressive in a demo and dies a month after launch.

Choosing the first hypothesis

A week of audit usually surfaces five to eight places where AI pays off. You cannot take them all at once — the team will spread too thin. I score each hypothesis on four criteria:

  • Frequency. The task repeats daily, not once a quarter.
  • Data. The material already exists in digital form and is available without six months of approvals.
  • Verifiability. There is a way to tell a good answer from a bad one, ideally by one expert in a couple of minutes.
  • Cost of error. If the system gets it wrong, someone notices and corrects it before it reaches a client or the books.

The first task should score high on all four. Not the most valuable one — the most verifiable one. You will capture the value on the second and third iteration, once the team trusts the output.

The pilot: two to four weeks and honest metrics

A pilot runs on your data, not on a demo set. Before you start, agree on three numbers: quality (the share of answers an expert accepts without edits), cost per request, and time to result. If the metrics do not add up in a month, the hypothesis closes. That is not a failure — it is six months saved.

A pilot that cannot be closed is not a pilot. It is a commitment the team will drag along for years.

Where projects usually break

The first trap is data. It turns out the policies exist in three versions, part of them only as scanned PDFs, and only one person knows which is current. Until that is sorted out, no model will help: it will faithfully answer from the outdated document.

The second is a missing process owner. If no specific manager sees their own numbers improve, adoption stops at “we tried it, interesting”. You need that owner from day one, not after a successful demo.

The third is integration. A model that answers in a separate window loses to habit. What works is what is embedded in the system where people already spend their day: the CRM, email, a messenger, the accounting tool.

What to do this week

Pick one process, count the hours it eats per month, and find one repeating step inside it with a verifiable result. That is enough to begin: the rest becomes clear from data, not from a deck.