The pattern is familiar. Someone sees an impressive demo, a licence is bought, and three months later a handful of people use the tool for drafting emails while the problem that justified the purchase is untouched. The tool wasn't bad. Nobody had worked out where in the actual work it was supposed to fit.
Before choosing any AI product, I'd rather spend a few days mapping the work itself. It's unglamorous, and it's the cheapest way to avoid an expensive mistake.
What mapping the work means
Pick one workflow that matters, and follow a real piece of work through it from start to finish. Not the process document; what actually happens. For each step, write down:
- Who does it, and how long it really takes.
- What they need to do it: documents, systems, other people, judgement.
- Where it waits. Most delay isn't work, it's queues.
- What goes wrong, and how anyone finds out.
- What a mistake costs at that step.
Do this with the people who do the work, not just their managers. They know where the workarounds are.
What the map tells you
Once the map exists, good AI candidates tend to stand out. They're steps with a lot of reading, sorting, summarising, or drafting; a high volume of similar cases; and a cheap way to check the output. Poor candidates are rare, high-stakes judgements, or steps where the real problem is a missing system or an unclear decision.
Often the map shows the biggest win isn't AI at all. It's a form that collects the right information the first time, or an approval that doesn't need to exist. That's still a win, and it makes any later AI work easier.
Then choose the tool
With a map, a vendor conversation changes. Instead of "what can your product do?" you can ask "here's step four, here are twenty real examples, show me." You can measure the current baseline, so you'll know whether anything improved. And you'll know which people need to be involved for the change to stick.
- AI adoption
- Process mapping
- Discovery