The most common way to waste money on artificial intelligence is to start with the process that is most visible rather than the one that is most suitable. Visibility and suitability are unrelated, and confusing them is expensive.
Before we recommend building anything, we apply a short test. It is not sophisticated, but it filters out most of the bad ideas.
The four questions
1. Is it repetitive?
Does this process happen often enough that improving it matters? A task performed three times a year is rarely worth automating, no matter how painful each occurrence is. A task performed forty times a week is a different proposition entirely.
Be honest about frequency. People consistently overestimate how often the annoying tasks actually occur, because annoyance is more memorable than routine.
2. Is it language-heavy?
Current AI systems are strongest where the work involves reading, writing, summarising, classifying or reformulating text. They are weakest where the work requires precise arithmetic, guaranteed consistency, or access to information that exists only in someone's head.
If your process is mostly moving numbers between systems, you may want conventional automation rather than AI. That distinction saves a great deal of money.
3. Is a wrong answer survivable?
This is the question that gets skipped, and it is the most important one. Assume the system will occasionally produce something confidently incorrect, because it will. What happens then?
If the answer is "a colleague notices during review and corrects it", you have a good candidate. If the answer is "it goes directly to a customer" or "a payment is made", you need a review step, tighter constraints, or a different process.
4. Can you describe what "good" looks like?
If nobody in your company can articulate the difference between a good output and a mediocre one, no system can be built to produce good outputs. This sounds obvious. It stops more projects than any technical limitation.
Where the criteria live only in one experienced person's judgement, the first piece of work is extracting that judgement into something writable — not building software.
What usually passes the test
Across the companies we talk to, a few categories come up repeatedly:
- Incoming document handling — invoices, orders, applications and forms that arrive in varied formats and must be turned into structured data.
- First-draft correspondence — offers, confirmations, standard replies that follow a pattern but need adjusting each time.
- Internal knowledge lookup — answering "where is it written that…" from your own documentation instead of asking a colleague.
- Classification and routing — deciding which department, priority or category an incoming item belongs to.
- Summarising accumulated material — long email threads, meeting notes, support histories.
What usually fails it
Processes involving final decisions about people. Anything where the output goes straight into a legal or financial commitment without review. Work that depends on context nobody wrote down. And processes that are painful because they are badly designed — automating those simply makes a bad design run faster.
Start with one
The temptation after this exercise is to start three projects at once. Resist it. The first process you automate teaches you how your own company reacts — where review actually happens, who trusts the output, what breaks. That knowledge makes the second project much cheaper. Running three in parallel means learning the same lesson three times.
