You don't need an AI strategy. There, we said it. What your business needs, if AI tempts you at all, is one bounded experiment with an honest ending: a pilot small enough to be safe and rigorous enough to be believed.
The expensive failure isn't trying AI and finding it wanting. That's cheap, and you learn something useful from it. The costly version is the vague, sprawling "AI initiative" that never quite works, never quite dies, and makes every sensible attempt that follows harder to get approved. Here's how we'd run the version that ends in a decision rather than a shrug.
The pattern is a familiar one. Someone sees an impressive demo, a tool gets signed up for, and a few people are encouraged to "have a play with it". Nobody has defined what success looks like, nobody timed the existing process beforehand, and the tool was chosen before the task was.
Six months later, no one can say whether it worked. It either rolls on as a monthly cost that nobody wants to question, or it quietly stops and gets remembered as "that AI thing that didn't pan out". Neither result tells you anything you can act on.
Vendor-led trials have a similar weakness. A demo on tidy sample data says very little about how a tool copes with your real inbox, your real documents and your customers' real spelling. The only trial worth running is one built around your own work.
The best fit is work that's frequent, fuzzy and checkable. Frequent, so you'll see enough cases in a few weeks to learn something. Fuzzy, meaning it takes reading and interpretation rather than following fixed rules. Checkable, meaning a person can look at the output and tell quickly whether it's right. Reading, sorting, extracting and drafting all tend to fit.
A quick test: if you could write the whole process as a handful of rules on a single sheet of paper, ordinary automation will beat AI on cost and reliability every time. Save the pilot for genuine judgement-adjacent drudgery, like the document and email work we've written about.
It's also worth steering clear of tasks that are rare, tasks where a mistake can't be undone (anything that goes straight to a customer without a second pair of eyes, for instance), and tasks where the people doing them can't agree on what "right" looks like. If your own team can't agree, the AI has no chance of being marked fairly.
Picture a holiday park that receives a few dozen enquiries a week by email and web form. Someone reads each one, works out whether it's an availability question, a group booking, a complaint or something else entirely, and then replies or passes it on. It's frequent, it needs a bit of interpretation, and a person can check a category at a glance. That makes it a good candidate. (This is a hypothetical, but it's the shape of task that tends to suit a pilot.)
"AI will correctly categorise 90% of incoming enquiries, cutting first-response time by half." One sentence, numbers included. Now the pilot has a finishing line, and everyone will recognise success or failure when it arrives. A pilot without a hypothesis isn't an experiment. It's a subscription with optimism attached.
Before you touch any tools, time the job as it's done today. A fortnight of rough figures is plenty: how many items come in, how long each one takes, how often they're sorted wrongly, how long customers wait for a reply. Without that baseline, you'll finish the pilot with a feeling that things are better and no way of proving it.
The baseline also tends to be revealing in its own right. Plenty of businesses discover the problem isn't quite where they thought it was, and that's a perfectly good result before you've spent anything on AI.
A good pilot has limits you can state in a sentence each:
That last point deserves a proper look. Find out what the provider does with the information you send it, where it's processed, and whether it can be used to train their models. Where you can, use anonymised or test data for the trial. And keep client or customer records out of consumer-grade tools altogether.
Integrate lightly at first, too. The AI's output can land in a queue for a person rather than being wired into your live systems from the start. You're testing a hypothesis, not committing an operation.
Collect a representative set of real cases, somewhere between 50 and 100, including the awkward ones. Draw them from several months rather than just the last week, so seasonal oddities and unusual requests are in the mix. Then have someone who knows the job decide, in writing, what the right answer is for each one before the AI sees any of them.
This evaluation set is the heart of the pilot. It's what turns "seems pretty good" into "89% correct, and here's where it fails". It's worth holding a portion of it back, untouched, until the end, so you're not simply tuning the tool to pass a test it has already seen.
Count the errors by severity as well as by number. A newsletter enquiry filed under the wrong heading is an irritation. A complaint that gets mistaken for a routine question is a different matter. Ten small slips and one serious one are not the same result as eleven small ones.
Define the escalation up front too: below what confidence, or for which categories, does a human take over entirely?
A person reviews the output, with the context to judge it and the authority to reject it. This sounds obvious, but it's where many pilots quietly fail. After a week or two of mostly correct answers, reviewers start nodding things through without really looking. Spot-checks help, and so does slipping in a few known-wrong cases now and then to see whether they get caught.
Involve the people who do the job today. They know where the awkward cases hide, and their trust is what any eventual rollout depends on. Tell them plainly what the pilot is for, and that it's a test of the tool, not of them.
When the window closes, compare the full process against your baseline: accuracy, speed, and the time spent reviewing and correcting, plus the running costs. An AI that's 90% right but doubles the checking effort has answered your hypothesis, just not the way the vendor hoped. The same goes for one that saves time but needs a paid subscription that costs more than the time it saved.
The pilot closes with one of three honest outcomes: adopt it and integrate it properly, adjust it and re-test, or retire it with the evidence filed away for a year's time, when the technology will have moved on. All three are good results, because all three are decisions, made with your data on your task.
Whichever you reach, write it up on a single page: the hypothesis, what you measured, what it cost, what you decided, and what you'd change next time. It takes an hour, and it's the difference between a lesson learned and a vague memory.
That's what a few weeks and a modest budget buys, and it's the approach behind our AI integration work: evidence first, commitment second, hype nowhere.
If there's a task in your business you suspect AI could lift off someone's desk, we'd be happy to help you design the experiment that finds out properly.