Most Artificial Intelligence projects don't fail because of the technology. They fail because they start in the wrong place: the tool gets chosen before the problem, a huge front is opened instead of a small one, and nobody measured how things were going before touching them. This guide runs the other way around — the order that actually works.
1. Start with a concrete pain point, not with the technology
The right question isn't "what can I do with AI?". It's "what is costing me time and money every week?". It sounds obvious, but it's the exact opposite of how it usually goes: someone sees an impressive demo, gets excited, and then looks for somewhere in the company to fit it. That road almost always ends in an expensive tool nobody is using three months later.
A good first candidate meets four conditions:
- It's repetitive. Someone does it the same way over and over, many times a week.
- It's measurable. You can put a number on it: hours, emails, orders, days of delay.
- It hurts. If it disappeared, someone would notice and be grateful the very next day.
- It's contained. It starts and ends somewhere clear, without depending on half the company.
Typical examples: sorting and answering the emails that land in the general inbox, moving data from invoices or delivery notes into a system, answering the same twenty customer questions, or putting together the same report by hand every Monday.
2. Measure the starting point before you touch anything
This is the step almost everyone skips, and it's the one that later makes it impossible to show the project was worth anything. If you don't know how long it took before, you won't be able to say it takes less now: all you'll be able to say is that "it seems to be going better", which convinces nobody who signs off budgets.
Over one or two normal weeks, write down things like these:
- How many times a day or a week the task happens.
- How long it takes each time, from start to finish.
- How many errors or reworks it generates.
- How long the customer waits for an answer, if they're affected.
Tip: you don't need a sophisticated measurement system. A spreadsheet filled in by hand over two weeks is enough, and it is worth more than any estimate made from memory — which is consistently and badly wrong in both directions.
3. Check what data you actually have
There's a myth that using Artificial Intelligence requires millions of perfectly organized data points. To train a model from scratch, it does. But most company projects today don't train anything from scratch: they build on existing language models and connect them to the knowledge of the business.
And that knowledge is almost always already somewhere: manuals, catalogs, old emails, the support ticket history, internal procedures, the ERP. It isn't an elegant data warehouse, but it's usually enough to get going. What matters isn't the volume, but that it is correct and accessible: an assistant that answers with last year's catalog does more damage than no assistant at all.
Before going any further, answer three questions:
- Where does the information the system needs actually live?
- Is it up to date, and who is responsible for keeping it that way?
- Is there personal or confidential data involved? If there is, that determines where the information can be processed, and it has to be decided up front, not afterwards.
4. Run a small test, but a real one
A useful pilot is small in scope but real in its conditions. It isn't a demo with three hand-picked examples: it's the system handling genuine cases, with genuine data, and with the people who will be using it afterwards.
A well-planned pilot has:
- A minimal scope. One process, one department, one type of query.
- A short timeframe. Weeks, not quarters. If it needs six months to show any signal, it's badly sized.
- A success criterion written down before you start. "Resolve 60% of type X queries without human intervention while keeping satisfaction steady" is a criterion. "See how it goes" isn't.
- A dignified way out. If it doesn't work, you switch it off and you've learned cheaply. That's a result too.
5. Put someone in charge of oversight before letting the system run on its own
At the beginning, everything the system produces should pass through human eyes. Not out of distrust, but because it is the only fast way to find the odd cases: the question nobody anticipated, the document in a different format, the customer who writes in a way that breaks the flow.
That oversight eases off as the data justifies it: first you review everything, then a sample, then only what the system itself flags as doubtful. It's a gradual, results-driven process, not an overnight decision. And it's worth always leaving a clear escape route to a person — especially if there are customers on the other end.
6. Scale only what you have already proven
When the pilot meets its success criterion, you have something far more valuable than a working system: you have internal proof, with numbers from your own company, that this works. That proof is what convinces the rest of the organization and what justifies the next step.
From there you scale in two directions, and it's best not to mix them:
- In depth: the same process, with more cases, more volume or more autonomy.
- In breadth: the same approach applied to another similar process, reusing what's already been built.
The three mistakes we've seen most often
Starting with the hardest thing. Choosing the company's most critical and complex process as the first project is the fastest way to burn through the budget and everyone's patience. The first one should be useful, yes, but above all it has to be achievable.
Leaving out the person who does the work. Someone who has spent five years doing that task by hand knows exactly where the exceptions and the odd cases are. If they aren't involved from the start, those cases will show up anyway — but in production and by surprise.
Mistaking the tool for the solution. Buying an AI platform isn't implementing AI, just as buying an ERP isn't putting the company in order. What solves the problem is the work of connecting that technology to your particular operation.
And if the answer turns out to be no
Sometimes the honest conclusion of this process is that Artificial Intelligence isn't the answer: the process is poorly defined, the data doesn't exist, or the problem is fixed far more cheaply with a simple integration between two systems. Getting there in three weeks and with little spend isn't a failure — it's exactly what starting small and measuring is for.