· 4 min read
Measure the workflow before you automate it
Most AI business cases count minutes saved and miss where the time actually goes. Baseline the wait, not just the work, before you build anything.
A team wants to automate how it answers customer questions about invoices. The work is simple. Someone opens the request, finds the invoice, checks the payment status, and writes a reply. It takes about six minutes.
There are around 400 of these a month. That is 40 hours, or a quarter of one person’s job. An AI agent could prepare most of those replies. The business case writes itself.
Then someone pulls the timestamps. The typical request waits two days before anyone opens it. The slowest tenth wait a week. Customers are not upset that the reply takes six minutes to write. They are upset that it takes three days to arrive.
The agent would still help. But not by the amount the business case claimed, and not in the place it claimed. The team almost built a solution for the wrong number.
Hands-on time is not elapsed time
Every piece of work has two clocks. Hands-on time is the minutes someone is actually working on it. Elapsed time is the clock time between the request arriving and the job being done.
In most office work, the first is a sliver of the second.
| Step | Hands-on | On the clock |
|---|---|---|
| Waits in the shared inbox | 0 min | 2 days |
| Someone finds the invoice and checks payment | 4 min | 30 min |
| Someone writes and sends the reply | 2 min | 10 min |
| Total | 6 min | about 2 days |
Six minutes out of two days is 0.2%. Automating that 0.2% feels like progress. The customer never notices.
Aim at the wait instead and the picture changes. Sometimes the fix is an agent that prepares the reply the moment the request lands. Sometimes it is a routing rule, an owner for the inbox, or a fixed time each morning when the queue gets cleared. You cannot tell which until you have measured where the time goes.
Capture four numbers before you build
You do not need a research project. You need four numbers, taken from a sample of the last month’s work.
- Volume. How many items a week, and how much that swings. A team that handles 100 a week on average but 300 in the last week of the quarter has a different problem than one that handles a steady 100.
- Hands-on time, as a range. Fastest, typical, slowest. Ask the person who does the work to time three real items themselves.
- Elapsed time, as a middle and a tail. The typical item, and the slowest tenth. Averages hide the pain. Nine requests answered in an hour and one that sits for ten days give an average of about a day. Nobody’s request actually takes a day.
- Rework. How often does the result come back? Corrected, reopened, escalated, or complained about.
Most of this already exists in your systems. Tickets, CRMs, and shared drives record when something was created, first touched, and closed. Pull twenty items and read the timestamps. Two afternoons is enough. It is far cheaper than building the wrong thing.
Turn hours into something a budget recognizes
Saved hours are not savings. They become savings only when they turn into one of three things:
- Work you would otherwise pay for. A hire you can avoid, or contractor hours you can drop.
- Revenue you are delaying or turning away. Slow quotes lose deals. Slow onboarding delays billing.
- Mistakes you stop paying for. Refunds, rework, write-offs, and findings from a compliance review.
Take our invoice team. If an agent removes two-thirds of the 40 hours, that is about 27 hours a month. Whether that is worth building depends entirely on what those 27 hours become. Faster replies that keep a customer from leaving is one story. A slightly calmer week for the team is another.
Both are legitimate. But they are different arguments, and it is better to know which one you are making before you spend the money.
Decide the stopping line first
Before the pilot starts, write two sentences: “We will continue if the typical wait drops below X.” “We will stop if it has not moved by Y.”
The exact numbers matter less than the fact that you chose them before you saw the results. Afterward, everyone finds a reason the outcome is good enough. A line drawn in advance is the only kind that holds.
Measure again, the same way
When the pilot is done, take the same four numbers from the same kind of sample, using the same timestamps. Changing how you measure looks exactly like changing the result, and nobody, including you, can tell them apart.
A workflow you have not measured is an opinion. One you have measured is a decision.
If you would rather have the numbers without the spreadsheet weekend, that is what a Process / ROI Assessment is for: a measured verdict on one workflow before anything is built. If you are still deciding what to measure first, start with how to choose your first AI workflow.