Somewhere around the first renewal, someone asks whether the AI tools were worth it. The useful answer compares the work now with the work before, and in most businesses nobody wrote down the before. What is left is one person saying it saves them a day a week and another saying they stopped using it, and neither is something a finance director can sign.
The fix costs an afternoon, and it has to happen before anyone starts.
Why a published figure does not answer it
Vendors and analysts publish productivity figures, and some are carefully made. Each was measured on someone else's work, with their process, their checking and their idea of done. Because your proposals, your client letters and your month-end close are different, the only figure that answers the question for your business is one measured on your work.
What to write down before you start
Pick the specific tasks the first team will use AI for, and for each one record six things on a single page:
- The task, defined tightly enough that two people would agree when it is done.
- How often it happens, per week or per month.
- How long it takes now, timed on a few real instances rather than estimated from memory.
- Who checks it, and how long the checking takes.
- What goes wrong now: rework, errors caught late, complaints.
- What better would mean for this task, which might be faster, fewer errors or the same speed with less of the work people dread.
Keep a handful of real examples of each task, with the confidential parts removed if need be, because they become the material you test on at the start and at every re-run.
How to measure after without fooling yourself
Measure the same tasks, done by the same people, on real material, and include the time spent checking.
Also count the outputs that were thrown away. A tool that produces a usable first draft most of the time and a useless one the rest has a cost that a timing of the good drafts alone will never show.
The first week flatters any tool, because people are trying it on the tasks it suits and paying it attention. By the third or fourth week the novelty has gone and the tool is part of an ordinary day, which is when to measure.
The three results, and what each one means
- If there is a clear saving on time, quality or both, keep the use, write it into the register with the result and widen it to the next group once their permissions have been checked.
- If no time is saved but the people doing the work value a gain, such as fewer errors or less of the task they dread, the use can be worth keeping, as long as the decision is deliberate.
- If checking swallows the saving, or there is no gain at all, stop or change the task. Sometimes the answer is that a plain workflow would do the job better, and finding that out early is a result too.
Whichever it is, the people who do the work judge it. They know whether a saving held up or just moved the effort somewhere else.
What not to count on its own
Usage figures show who opened the tool, and a report showing everyone active every day can sit alongside no change in the work at all. Self-reported time savings rise with enthusiasm and fall with frustration. When the results come from one enthusiastic person, they describe only that person.
Turning it into a business case
Multiply the time saved per task by how often it happens and by how many people do it, then set that against the seats, the running costs and the time spent checking. Present it as a range and have it signed off by the people whose work it describes. With that sign-off, even a modest figure carries more weight with a board than a large one nobody can explain.
Keep measuring
Because the models behind these tools change without notice, a task that worked well in March can drift by September. Keep the examples you tested on, re-run them every quarter and whenever the vendor announces a model change, and compare the results with the last run. It takes an hour, and it tells you when something has moved before your people stop trusting the output, which is how most pilots fade.
Where this fits
The route is built to measure this way. Adopt ends with a test on the work your first team does every day, against the before they wrote down, and every piece of Build closes with Test on your own work. After that, the re-runs are part of the improving work in Trackside. Proof explains why we publish results only from named engagements, and only where the client allows it.