Most large companies have already tried AI in some form. Someone in sales writes emails with a chatbot. IT has launched a pilot assistant. Management has sat through a presentation on “transformation”. And yet on Monday the reports are still written by hand, and the meeting memos are still late.
The reason is rarely the technology. Usually the AI project starts too big, without one clear process and without a measure of success. Here is how we start, and why.
1. Pick one process that hurts
Don’t start with “where could we use AI?”. Start with “what slows us down every week?”. A good first process has three signs:
- it happens often: every day or every week;
- it involves a lot of writing, retyping or pulling data together from several places;
- it has an owner who feels the pain: a sales or operations director.
Examples: a memo after every sales meeting, the weekly management report, maintenance protocols, processing incoming documents. One process is enough. You will pick the second one more easily once the first is working.
2. Measure how it works today
Before you change anything, record the baseline. How long does the process take? How often is it late? How many manual steps are there? Where does data get lost?
You don’t need a big methodology. A few conversations with the people who do the work and a look at real (or anonymised) documents are often enough. Without these numbers you won’t be able to say whether AI helped.
3. Ask for a demo, not a slide deck
A slide deck promises. A demo shows. Ask the provider for a working solution on your process, with your document template and synthetic data: realistic but made up. That way your real data stays in the company, and you see what the result will look like.
The right question in the demo is not “how clever is the AI?” but “what happens when the recording is unclear?”. The answer should be specific: anything unclear is flagged “For review” with a quote from the source, and a person decides.
4. Bring in IT and security at the analysis stage, not at the end
In a large company one person doesn’t make the decision. The owner of the pain (the sales or operations director) leads. IT and information security guard. Management approves.
The earlier IT sees the architecture, the fewer the surprises. Their questions are predictable:
- Where is the data hosted? (The answer you want: in the EU.)
- Does AI have direct access to the ERP or CRM? (The good answer: no; AI only receives the data it needs, and anything written goes through rules.)
- Is there a log of actions and approvals?
- Is there an NDA and a data processing agreement?
If the provider struggles with these questions, that is a signal.
5. A 4–6 week pilot with real users
The pilot is where you learn whether the solution works in real life. It is limited: one process, one team, a clear deadline. You measure the same things you measured in step 2, plus one more: whether people actually use it.
Adoption is often harder than the technology. So the solution has to remove work, not add it. If the sales rep only records the meeting and approves the finished memo, they have a reason to use it. If they have to fill in yet another form, they don’t.
6. A management decision based on numbers
After the pilot, management gets a short summary: what it was like before, what it is like now, what the AI running costs are and what comes next. AI costs for document processing are usually small per unit, but put them under a monthly cap so there are no surprises.
If the impact is there, you scale: to more teams or to the next process on the same foundation. If it isn’t, you stop with a small loss and a clear understanding of why.
Common mistakes
- Starting with a platform, not a process. You buy an “AI solution” and then look for somewhere to use it.
- Replacing your systems. AI can work on top of the ERP, CRM and Microsoft 365 you already have. Replacing the core is rarely needed for the first result.
- Promising numbers before the pilot. The honest promise is “we will measure”, not “we will save 50%”.
- Leaving AI without a person. The person who approves is both a safeguard and the way the team gets used to the change.
In short
One process, one baseline, one working demo, one pilot with real people and one decision based on numbers. It is slower than a big presentation, but much faster than a big project that never reaches Monday morning.
If you want to see what such a demo looks like, book a demo or read our sales meeting case study.