Measure AI in your organization's own numbers, not hours saved.
Ask a team how its AI pilot went and the answer usually arrives in hours. Someone saves forty minutes on meeting notes, someone else drafts proposals faster, and the total gets added up into a figure that sounds large. Then the director who approved the spend looks at the monthly report and can't find it anywhere.
Hours saved don't land anywhere.
An hour saved is real to the person who saved it. It just doesn't move a line that anyone else watches. The budget stays the same, and the time usually gets absorbed by the next email or meeting. When finance asks what the tools paid for, "about two hours a week each" is an estimate of a feeling, and it's hard to defend twice.
The other problem is that hours invite the wrong conversation. If the only proof of value is time freed up, the obvious next question is whose time, and what happens to the people who had it. Most leaders we work with don't want that to be the story, and their teams can tell when it is.
Start from the report you already read.
Every organization already has a handful of numbers it takes seriously. They show up in the board packet, the monthly operations review or the grant report, and people get asked about them when they slip. A town office tracks how long a permit takes to issue. A clinic watches its no-show rate and how many days a referral sits before someone calls the patient. A manufacturer cares how quickly a quote goes out, and a professional firm cares how long it takes to turn finished work into cash.
Those are the numbers AI should be measured against. They existed before anyone bought a license and they will still matter if the tools change, which makes them harder to argue with. For any piece of AI work, the useful question is which of these numbers it was meant to push.
If a use case can't name the number it is supposed to move, it is a hobby, and that's allowed, but it shouldn't be in the budget request.
Work backward from the number to the task.
Pick one number and trace it down to the work underneath it. Say quote turnaround at a small manufacturer is running long. The delay usually isn't one big thing. It's the estimator retyping specs from a customer email, hunting for last year's price on a similar part, and writing the same cover note for the hundredth time. Any of those steps is a candidate for AI help, and each one has a clear connection to the number at the top.
Going in this direction also tells you what to train people on. A team that knows its target is faster quotes will learn to pull specs out of an email and draft a cover note from a template. That is a narrower lesson than "get better at AI," and people retain it because they use it the next morning.
Get a baseline before anything changes.
The most common mistake is measuring only after the tool is in place. Without a before figure, a good month looks like proof and a bad month looks like failure, and neither tells you much. Pull the last few months of the number from whatever system already holds it (the accounting software, say, or the scheduling calendar) and write it down with the date you pulled it.
Attribution will never be clean. A new hire, a price change or a slow season can move the same number, and AI will get blamed or credited for things it didn't do. Two habits help. Note anything else that changed during the period, so the story stays honest. And where it's practical, let part of the team use the new approach while the rest works the old way for a few weeks, then compare. Say a front desk of six splits into two groups of three for a month on reminder calls; the difference between them is easier to believe than a before-and-after on its own.
Report in the language of the meeting.
When results come in, report them in the same units the number is usually reported in. If the operations review talks about days to issue a permit, say the average went from one figure to another, over which period, with what else changed. Leave the hours out unless someone asks. A modest change in a number people already care about will get more attention than a large count of minutes nobody can find.
Be careful with what you claim. One good quarter can still be a fluke. Say a clinic reports that referral follow-up dropped from about nine days to six over two months, during which it also added a part-time coordinator. That honest version earns more trust than a clean headline. Some of what AI helps with, like fewer dropped follow-ups or a calmer inbox, won't show up in any of these numbers. That's fine, and it can be reported separately; it just shouldn't be the reason the budget gets approved.
A one-page worksheet for each use case.
Fill one of these in before a use case starts, and update it when the review comes around. If a line is blank, the use case isn't ready.
- Use case: one sentence on what the AI does and who uses it (for example, "drafts the first reply to new permit inquiries for the front counter").
- Number it should move: one figure your organization already reports, named exactly as it appears in the report.
- Where that number lives: the system or report it comes from, and who pulls it.
- Baseline: the value over the last three to six months, with the date it was pulled.
- The task in between: the specific step in the work the AI changes, and how that step feeds the number.
- Other changes: anything else happening in the same period that could move the number (staffing, pricing, seasonality, a new policy).
- Comparison: before-and-after only, or a split group, and for how long.
- Review date: when someone will look at the number again, by name.
- Decision rule: what result means keep going, adjust or stop, written down before the results arrive.
