Measuring time saved honestly

Sooner or later someone senior asks how much time AI is saving. There are two easy answers, and both will hurt you. The first is a usage number: logins, prompts, active users. It measures activity, not value, and anyone who thinks for a moment knows it. The second is an extrapolated headline: take a survey where people say AI saves them "about an hour a day", multiply by headcount and salary, and announce a large figure. It's impressive right up until someone asks where the hours went.

The honest alternative is less dramatic and much more durable: measure specific workflows, before and after, using estimates from the people who do them, and say clearly what kind of number it is. This playbook is how.

1. 1

   Step 1: set the baseline.

   Time per instance, volume, a quality signal, date and source.

2. 2

   Step 2: change one thing, then wait.

   At least two or three weeks.

3. 3

   Step 3: measure after, the same way.

   Same question, same people, same sources.

4. 4

   Step 4: do the arithmetic, conservatively.

   And say which adjustments you've made.

5. 5

   Step 5: report it in a way that survives questions.

   One short block per workflow.

The principles

Four rules underpin everything below. If you only remember these, you'll be fine.

1. Measure workflows, not people. "The monthly client report" has a before and after. "Sarah's productivity" doesn't, and measuring it will make Sarah stop telling you the truth.
2. Baseline first. A number with no "before" is a guess. Get the before while it still exists.
3. Count checking time. Time saved is time to a usable output, including review and fixing. A draft in two minutes that takes an hour to correct isn't a saving.
4. Label your numbers. "Team estimate", "timed sample" and "system data" are different things. Say which one you're using. Rough and honest beats precise and invented.

Step 1: set the baseline

For each workflow you're working on, before anyone changes how they do it, collect:

• Time per instance. Ask three or more people who do it: "Thinking about the last few times, how long did this take you, start to finish?" Use the middle answer, not the average, so one outlier doesn't skew it.
• Volume. How many instances per week or month, across how many people. Get this from a system if one exists (tickets, reports filed, proposals sent). Otherwise, ask the manager.
• A quality signal. Something that already exists: number of review rounds, rework, error rate, turnaround time, complaints. Don't invent a new quality score for this.
• Date and source. Who told you, and when.

If you can, also do a timed sample: ask two people to note start and finish times on the next real instance. Estimates are usually in the right range but tend to drift. A couple of timed instances keep you honest.

Write it up in one line per workflow:

Step 2: change one thing, then wait

Run your sprint or session on the workflow. Then leave it alone for at least two or three weeks before measuring again. The first few attempts with any new method are slower.

Step 3: measure after, the same way

Repeat exactly what you did for the baseline: the same question to the same people, a couple of timed instances, the same volume source, the same quality signal. Using the same method matters more than using a perfect one, because what you're reporting is the difference.

Add three questions you couldn't ask before:

- Are you still using it for this? Every time, sometimes, or not any more?
- What do you still do yourself?
- Has anything got worse?

The first tells you about adoption honestly. The third is the one most people skip, and it's the one that protects your credibility.

Step 4: do the arithmetic, conservatively

For each workflow:

Time saved per month = (baseline time − new time) × instances per month × share of instances now done the new way

Then make three adjustments, and say you've made them:

• Use the lower end of any range people give you.
• Only count instances actually done the new way. If half the team has switched, count half.
• Don't convert to money unless asked, and if you are, use a figure finance gives you rather than one you've worked out. "Hours back" is a cleaner claim than "pounds saved", because the hours usually go into other work rather than off the payroll, and finance knows that.

Step 5: report it in a way that survives questions

Each workflow gets one short block:

Monthly client report (account team, 6 people)
Before: ~3h per report, 2 review rounds (team estimate + timed samples, March)
After: ~1h15 per report, 1–2 review rounds (same method, May)
Adoption: 4 of 6 people, every report; 2 not yet
Approx. time back: 25–30 hours a month
What got worse: nothing reported; first drafts occasionally miss client-specific terms, now in the guide
Method: team estimates, timed samples, report count from CRM

That last line is what makes the rest believable. Anyone can check it.

Then, separately, add the things that don't reduce to hours but matter: fewer review rounds, faster turnaround for a customer, a task that used to be skipped now getting done. Report these as what they are rather than converting them into time.

When the answer is "not much"

Some workflows won't improve. The tool isn't good enough at the core task, the checking takes as long as the doing, or the team hasn't changed habits. Report it anyway:

This is one of the most useful things you can put in a report. It shows you're measuring rather than marketing, which makes every other number on the page more credible. It also stops other teams wasting time on the same dead end.

Mistakes to skip

• Reporting licence usage as impact. Fine as a footnote on adoption. Never as the headline.
• Survey-and-multiply. "People say they save an hour a day" times headcount is a number nobody can defend.
• Measuring too early. Week one is the learning curve, not the result.
• Ignoring checking time. It's where most inflated claims hide.
• Changing the method between before and after. If you estimated before and timed after, you're measuring the difference in method, not the workflow.
• Hiding the failures. They're your credibility.

At the end you should have

• A baseline for each workflow, with method, source and date
• An after measurement taken the same way, at least a few weeks in
• A conservative time-back figure per workflow, with adoption counted honestly
• A one-block summary per workflow, including what got worse and how you measured
• At least one honest "this didn't work", if you've been at it long enough

The Role Book has a full lesson on measuring time saved without lying, including the baseline interview, a measurement tracker and the report template that turns these blocks into a quarterly update leadership keeps reading.