In most companies, the AI decision starts with a tool. Someone watches a demo, licenses are bought, the team is informed and a few training sessions are held. Three months later most of the licenses sit unused. The cause is usually neither a bad tool nor a resistant team: the tool was dropped into a process that had never been described.
There is a sturdier route: pick a single process, measure how it works today, and compare the result of a 30-day pilot against that measurement. The tool comes at the end of that sequence. In this article we walk through the method step by step, using a representative example built around getting incoming customer requests to the right person.
Why does starting with the tool stall?
The tool is visible: it can be demoed, it has a price, it can be presented to management. The process, in most companies, is not written down; it lives in the habits of whoever does the work. You cannot present or budget a problem like "nobody knows who handles which request," so the decision gets made around what is visible.
Yet an AI tool takes over one specific step of a process. If nobody has defined which step, the team cannot see where the tool connects to their work, and they go back to the method they know. The result looks like resistance, but its source is a missing definition.
The right sequence: process, measurement, tool
The first step is to write down the process: which steps there are, who does each one, how often and in how much time. This is worth doing even without AI; many companies put their own process on paper for the first time at this stage and see gaps they had not noticed.
The second step is measurement. Before the pilot starts, the process is recorded for one week without changing anything. Without that record, all you have at the end of the pilot is an impression, and the excitement of trying something new almost always pulls impressions upward. Only after these two steps is the tool chosen; once the process and the measurement are clear, the differences between the options shrink too.
A representative example: getting incoming requests to the right person
Picture a mid-sized company. Around 400 requests a month arrive through the website form and the general email address: sales questions, technical support, billing, returns, complaints and job applications. A single customer service coordinator reads them and forwards each one to the right person. Because the coordinator has other work during the day, the inbox only gets checked every few hours.
Why is this process a good candidate?
The process chosen for a first pilot has to meet four conditions together, and this one meets all four. It runs often: 400 requests a month is more than enough to build up data within 30 days. Its rules can be described: which type of request goes to whom fits on a single page. Its data already sits in a system: form entries and emails. Its cost of error is low: a request sent to the wrong person is fixed in a few minutes, and nothing reaches the customer, because a person still writes the reply.
One issue has to be settled before the tool is chosen: the requests contain personal data such as names, phone numbers and order details. So the pilot runs on an enterprise, privacy-compliant license under which the data entered is not used to train models. Free and individual plans are not suitable for this process.
Baseline week: four numbers
In the week before the pilot, the coordinator does the work as usual and records four things in a table: how many requests came in that week, how many minutes it took to read and route one request, how many requests went to the wrong person and came back, and how many hours went into this work in total. At the end of the week the table shows about 100 requests, an average of 4 minutes each and a total load of nearly 7 hours. A request took an average of 5 hours to reach the right person, and 15% of requests went to the wrong person first.
It matters that the person doing the work keeps the record, not the manager. A measurement kept by the manager leads the person being measured to work faster that week, and the baseline looks better than it really is.
Four weeks
Day 30: the numbers
| Metric | Baseline week | Week 4 |
|---|---|---|
| Requests per week | About 100 | About 100 |
| Time for a request to reach the right person | 5 hours on average | 40 minutes on average |
| Time spent per request | 4 minutes | 1.5 minutes |
| Total weekly workload | About 7 hours | About 2.5 hours |
| Requests sent to the wrong person first | 15% | 18% |
Anyone looking only at the first four rows would call the pilot a success. The last row says something else: the misrouting rate did not fall, it rose. Almost all of the increase comes from returns and complaints. The week-four conversation shows the same picture: the team is happy with the speed, but says it double-checks every return request.
The decision: fix and repeat
The three options for the day-30 decision were written down at the start of the pilot. Scaling required three conditions together: meaningful improvement in time, an error rate no worse than the baseline, and a team that wants to continue. The first and third were met; the second was not. There is no reason to stop either, since the improvement is clear. The right call is to fix the problem and repeat the 30 days.
The source of the problem is the definition gap spotted in week one, not the tool. Because the company never wrote down the difference between a return and a complaint, the machine cannot make that distinction consistently either. The fix has two parts. First the distinction is turned into a written rule; for example, a request that includes an order number and asks for a refund is a return. Then, throughout the second pilot, these two categories are reviewed one by one by the coordinator instead of being approved in a batch. At the end of the second 30 days, the same four numbers will be reviewed again.
This is also the real lesson of the example: the pilot did not just test AI, it exposed a gap in the company’s own process definition. Without the measurement, that gap would have survived as an impression along the lines of "the AI mixes up returns."
Which processes not to start with
In the same company, the first two candidates that come to mind would not have been good starting points. Compiling the weekly management report takes time, but it happens only four times a month. You cannot make a decision on four repetitions at the end of 30 days; even if things improved, you would not be able to see it. Pre-screening job applications runs often, but its cost of error is high: a candidate wrongly rejected is an outcome you cannot undo, the process directly affects people, and it is sensitive from a personal-data standpoint.
Both processes can be tackled later. But forcing a process that fails one of the four conditions into a first pilot makes the pilot stall at exactly that point and leads to the false conclusion that AI does not work.
Who should run the pilot, and what should the team be told?
The pilot needs a single owner, and that person should come from the business, not from IT. In the example it is the customer service coordinator, because nobody is better placed to judge whether a routing decision is correct. IT supports access, security and licensing. The process owner needs to set aside 4–6 hours a week for five weeks, including the baseline week. That time is the real cost of the pilot; if it cannot be found, it is better not to start.
Before the pilot starts, the team’s two questions need answers. The first: "Will this take my job?" In the example about 4.5 hours of the coordinator’s week are freed up; where that time goes, for instance into replying faster to waiting requests, should be stated in writing from the start. The second: "Who is accountable if a request is misrouted?" The rule is simple: the machine suggests, a person approves, and accountability stays with the approver.
Where to start in your own company
Incoming requests are only one example. Other processes often meet the same four conditions: preparing the first draft of a proposal, extracting tasks and next steps from meeting notes, summarizing long correspondence, and transferring data from order and invoice documents into a system. You can score which one is the right candidate for you by looking at frequency, clear rules, data access and cost of error.
AI speeds up a system that works; it does not stand in for one that has not been defined. That is why the most lasting output of a first pilot is often not a tool but a process that has been written down and measured. The guide below includes a scorecard for rating your own candidate processes and a week-by-week pilot plan.