Most organisations don’t have an AI problem. They have a pilot graveyard: a handful of promising demos that impressed a room, then quietly went nowhere. The tool worked. The enthusiasm was real. And six months on, nobody uses it.
When we look at why, the cause is almost never the technology. It’s the order the project was picked in. Teams start with the tool (“let’s do something with Copilot”) instead of the work. So here’s the order we use instead.
Start with the work, not the tool
A good first use case is boring on purpose. It’s a task that happens often, follows rules, eats real hours, and doesn’t need perfect judgement. Think triaging inbox requests, drafting a first pass of a report, pulling data out of forms, or summarising long documents into a standard shape.
The test we use: if this ran every day and saved twenty minutes a time, would anyone notice? If the honest answer is no, it’s a demo, not a project.
Score use cases on two axes
Before building anything, rank the candidates on two things:
- Value — how much time, money, or risk it removes, and how often.
- Feasibility — how clean the data is, how clear the rules are, and how much sign-off it needs.
The winner is rarely the flashiest idea. It’s the high-value, high-feasibility one in the corner that everyone overlooked because it wasn’t exciting. Ship that first. It builds trust and pays for the next one.
A pilot that saves one team two hours a week and is still running next quarter beats a headline demo that nobody opens twice.
Design for the handover on day one
The moment a pilot depends on one enthusiastic person, it’s fragile. Decide up front who owns it, how they’ll know it’s working, and what happens when it gets something wrong. Automation without an owner and a fallback isn’t finished, it’s a liability waiting for a bad week.
Get governance in early, not at the end
The fastest way to kill momentum is to build for three months and then meet your risk, legal, or data team for the first time. Bring them in at the scoping stage. Agree what data the tool can touch, where it runs, and how decisions are logged. Done early, governance is a green light. Done late, it’s a wall.
Then train the people who’ll actually use it
A working tool that no one trusts still fails. The last step is hands-on training for the team who run it every day, in their own workflow, with their own examples. That’s what turns a pilot into a habit, and a habit into results you can measure.
None of this is exotic. It’s just the boring order: find where it fits, prove value, automate, govern, train. Do it in that order and the pilot ships. Skip a step and it joins the graveyard.