Choosing an AI tool
Write the job down in five lines, then judge every product against that page rather than against its own demonstration.
Choosing an AI tool begins with a job, and the job has to exist on paper before you look at any product. Write down what starts it, what goes in, what comes out, who checks it, and where the result goes next. Hold every product up against that one page. The shortlist gets short very quickly.
Choosing an AI tool starts with a written job
Writing it down first protects you from the commonest way a purchase goes wrong. Somebody watches a good demonstration, likes it, then goes looking for a job it can do. That order is expensive, because the tool sets the problem and the problem never quite fits the business.
Reverse the order. Pick a job you already do often, ideally one that irritates people, and describe it in plain sentences before you look at any product. The writing takes an hour. It can save you from an annual contract for something nobody needed.
The five lines that describe the job
Describing it means five lines, not a specification document. Anything longer starts to sound like a wish list.
Your trigger is the event that starts the work. The input is the material the tool receives, described by format rather than by name. Output means what a correct result contains, field by field. A reviewer is the person who checks it, by name. Finally, the next step says where the result goes once it passes.
Write those lines for the job as it runs today, not as you wish it ran. If the input is currently a photograph of a delivery note, write photograph. That single word rules out a good part of the market before you speak to anybody.
Why the input format decides more than the feature list
Of those five lines, the input causes the most surprises. Products describe what they can do with clean, typed text, because that is what their own examples contain.
Real work arrives in a rougher state. Scanned PDFs, forwarded email chains, spreadsheets with merged cells, handwriting photographed on a phone. So ask what the tool does with each format you genuinely have, one at a time.
A product that reads typed PDFs beautifully and guesses at scans is right for one job and useless for another. Volume belongs in the same conversation. Something that copes with 10 documents an hour suits a weekly task and fails a daily one, so give the supplier a real number rather than a rough sense of it. Sorting the source out is separate work, and preparing documents for AI is often the larger half of the effort.
The questions a demo will not answer
With the job written down, a demonstration becomes a test rather than a show. A demo only ever shows the tool working. It cannot show the tool struggling, because nobody builds a demonstration out of their worst day. So bring the questions the demo can’t reach.
What does the tool do when it is unsure: guess, flag it, or stop? How does somebody correct an output, and does that correction change anything next time? What comes back when the source document simply doesn’t contain the answer? Those three replies tell you more than an hour of features.
Ask what happens on the bad days
Those answers describe the tool. The next set describes the supplier, and choosing an AI tool means choosing a supplier at the same time.
Find out who you call when the output is wrong on a Friday afternoon, and get their response time in writing. Establish what happens to your material if you cancel, and how you get it back. Check which other companies handle your data as part of the service, because most providers rent their infrastructure rather than owning it.
None of that is an unusual request, and a good supplier answers plainly. The National Cyber Security Centre publishes guidance on assessing suppliers if you want a fuller list. Vague answers are the clearest early warning you will get, so treat them seriously and work through the other security questions before anything sensitive goes near the product.
Test it on your own material
Plain answers still need proving, and every serious supplier will let you run a trial. Use it properly. That means your documents, not the neat examples they offer to set up for you.
Pick 20 real items from the past month, and include the awkward ones you would normally hand to somebody experienced. Run them all through the tool.
Then count three things. How many outputs you could use unchanged, how many needed a small correction, and how many were wrong in a way that would have caused trouble further down the line. That sample is large enough to show a pattern and small enough to finish in an afternoon. Do the counting yourself, or sit beside whoever does it. Reading 20 outputs in a row teaches you the shape of a tool’s mistakes, which no specification will ever tell you.
Keep the trial results
Those numbers are worth more than the trial itself, so write them down before the impression fades. They become the baseline you measure against once the tool is live, and they tell you how much checking the job will need in its first month.
The time your team spends on that trial also belongs in the budget, alongside the licence. It is one of the lines people forget when they work out what a first AI job costs.
When is walking away the right answer?
The trial can also tell you to stop, and that verdict is easier to accept when you set it in advance. Decide what would make you say no before you run the trial, so the decision never turns into an argument about effort already spent. Three conditions justify walking away.
The first is format: the tool can’t take your input as it actually arrives, and fixing that costs more than the job saves. The second is checking: reviewing the output takes as long as doing the work, which moves effort rather than removing it. The third is the supplier: no straight answers on data, support or exit.
None of those three is a reason to abandon the idea of AI. Each one tells you the job, the material or the market isn’t ready yet, and any of the three can change within a year.
Walking away at that point costs you very little. You have written the job down, tested it against real material and learned what the work genuinely needs. Keep that page, because you can judge the next product in an afternoon rather than a quarter.
