Whose afternoon did the automation improve?

The generation time is the most photogenic number

The draft arrives in seconds. The colleague reading it still has to remove an unsupported promise, recover a missing detail and decide what can actually go to the customer. That is where a generation-time saving can become another person’s work. Before calling the automation faster, I would follow the enquiry through review, repair and maintenance to the point at which the reply is genuinely ready.

There may still be a worthwhile improvement, but it helps to name who receives it. The general inbox can lose routine handling while one specialist gains difficult repairs. Customers can get an earlier acknowledgement without the team gaining much free time. The one-week model below follows human minutes separately from machine runtime, then changes the number of exceptions to see how much of the apparent saving survives.

Google’s SRE discussion of toil distinguishes hands-on operational work from machine elapsed time and from engineering which produces enduring improvements. [1] The original example here follows human minutes across one week of enquiries. Every value is an invented planning assumption; there are no client results, measured productivity claims or conversion of released time into cash.

Begin with the same work on both sides

Assume one hundred enquiries take an average of three minutes each under the manual process, for three hundred human minutes. The baseline must include comparable work through the chosen completion point, not merely the first reply. If the manual average excludes complex cases while the automated side includes their repair, the comparison is unfair in the other direction. Define the cohort and outcome before calculating the saving.

The proposed workflow still needs 0.2 minutes of routine human handling per enquiry, totalling twenty minutes. Twenty-five enquiries receive a two-minute first review, adding fifty. Ten cases need a further eight minutes of exception repair, adding eighty. Weekly maintenance adds thirty. The total is 180 minutes, leaving 120 minutes of released capacity against the three-hundred-minute baseline.

The stages are deliberately distinct. Exception repair is additional work beyond any first review, so the example does not accidentally count the same two-minute check twice. Machine runtime is excluded from these human minutes; model charges or infrastructure costs need their own appropriate accounting. If an application runs for twenty minutes while nobody attends it, that is not automatically twenty minutes of staff effort.

The twenty-five reviewed cases are a choice in the example, not a finding that this sample catches every important error. A real trial also needs to look at accepted outputs the system never escalated. Fewer reviews could mean a reliable workflow or a detector that is missing its mistakes. Keep the resulting quality beside the time record, or an appealingly light review workload can be purchased by leaving somebody else to discover the problems later.

Watch the saving respond to exceptions

Keep the same hundred-enquiry workload and other assumptions, but let the automation produce twenty repair cases rather than ten. Repair work becomes 160 minutes. The new total is 260, leaving only forty minutes against the same manual baseline. The original hundred-and-twenty-minute saving has mostly disappeared without any change to the speed of generating a draft.

With routine handling twenty, review fifty and maintenance thirty, the fixed surrounding work totals one hundred minutes. Two hundred minutes remain before the manual baseline is reached. At eight minutes per repair, twenty-five exceptions exhaust the saving. This break-even count is useful because it names an assumption to investigate. It does not claim that twenty-five is an acceptable error count; some outcomes are unacceptable even when the arithmetic remains favourable.

The downloadable calculation keeps the routine fraction exact and reproduces those totals. The repair count is the next input worth measuring: does a case enter it only when a specialist takes over, or also when the first reviewer quietly fixes a missing detail? Under the latter rule, some of the supposedly cheap first reviews contain additional repair time. Record that boundary before timing the pilot, or the same effort could disappear into routine handling in one configuration and count as an exception in another.

A different workload needs a rebuilt baseline. More complicated enquiries might take people longer manually as well as create more automation repairs. That is not the same question as a worse configuration on the identical hundred cases. Keep the cohort and comparison visible when explaining a changed saving, so the team can tell whether the tool deteriorated, the work changed, or both. The old average cannot choose between those explanations by remaining conveniently available.

Minutes have owners and a shape

The hundred-and-twenty minutes may not become a free two-hour block. They could be scattered across a hundred small interactions, while the repair work interrupts one specialist at inconvenient times. That released capacity can still be valuable, but describe how it becomes usable: fewer context switches, a shorter queue, time for scheduled work or the ability to handle more enquiries without adding another task to an already full day.

Identify whose minutes change. Removing routine work from a general inbox while adding eighty minutes of difficult repair to the only integration specialist may create a bottleneck the aggregate hides. The minutes have different availability and opportunity costs even before anyone assigns a monetary rate. A useful report shows the distribution by role as well as the total, so a local saving does not become somebody else’s unplanned support burden.

Maintenance also has a shape. Thirty planned minutes updating rules and checking a sample is different from thirty minutes spread across urgent fixes after customers notice errors. Both belong in the effort record, but they imply different experiences and future risks. A tool can improve by turning reactive work into a manageable scheduled task, even when the immediate minute total does not fall dramatically.

Review and repair can occupy the same colleague while doing very different jobs. One makes a judgement the business still needs; the other reconstructs lost information or removes a promise the assistant had no basis to add. Count both, then ask why the second keeps returning. An assistant can improve a necessary decision without eliminating it. Repeated avoidable reconstruction is a reason to preserve the information earlier in the workflow, rather than teach the time sheet to regard it as normal review.

Run a trial which can answer the actual question

Record hands-on handling, review, additional repair and maintenance for an identifiable cohort, with a practical rule for when each starts and ends. Include rejected drafts and unresolved cases. If a person silently fixes errors while sending the reply, that time must not vanish because the tool recorded its generation as successful. Pair the effort with the resulting quality and completion state.

Keep an appropriate comparison, whether a previous comparable period or a deliberately reviewed parallel sample, and explain its limits. A quiet week is not automatically a fair baseline for a busy one. Learning effects matter as well: initial setup and training can be separate from recurring effort, but they do not cease to exist because the monthly report begins after launch. Show the period each cost belongs to.

A decision may still favour the tool when the direct time saving is modest. It might provide more consistent case records, faster acknowledgement or a useful service outside the usual response window. Establish those benefits from their own evidence rather than squeezing them into invented cash savings. Conversely, a large calculated time gain should not excuse a workflow whose unsupported commitments damage the service people receive. Compare a simpler process change too. A better intake form, an explicit account reference or a direct system integration might remove the same repetitive handling without generating a draft that then needs review. The useful comparison is between viable ways to improve the work, not only between the current manual process and the most impressive AI demonstration. That can lead to a smaller implementation with a clearer benefit.

Under these assumptions, ten repairs leave 120 minutes of capacity and twenty leave forty; twenty-five consume the saving altogether. A real adoption decision needs observed effort and acceptable outcomes for comparable work, including the roles that inherit the repairs. Then ask what the released minutes make possible: a shorter queue, fewer interruptions or time for planned work. That is a more useful answer to whose afternoon improved than the speed of the first generated paragraph.