How to stop an automation that still has work to do
Retire intake, accepted jobs and external authority in a deliberate order, so a late event cannot revive an obsolete process.
A time-only reporting example compares two improvements, their upkeep and the frequency at which either earns its setup effort.
The five-minute export is the easiest step to picture automating. In this invented weekly report, though, twenty-five minutes go on reconciling product names and fifteen on interpreting unusual results. Removing the export leaves most of the repeated preparation in place. Stable product references might remove more of it, at a higher setup cost. Comparing those two investments is more revealing than starting with the task for which an automation button is easiest to imagine.
The distinction is not between valuable people and unimportant clerical tasks. All three activities may be necessary while the process remains as it is. The question is which activity needs to recur in its present form. Interpreting a genuine variance can require judgement. Repeatedly establishing that Filter fine and Fine filter refer to the same configured product may be a repair for missing stable references upstream. Automating the repair and removing its cause are different investments, with different maintenance demands.
Google’s SRE workbook recommends measuring toil before choosing an improvement, including the engineering effort and ongoing maintenance, while recognising benefits an hours calculation misses.[1] The comparison here follows that discipline with explicit illustrative durations, not client savings or Google staffing targets. We can inspect what those assumptions imply and then change one of them. Reporting frequency turns out to be particularly consequential: the same implementation can look attractive weekly and difficult to justify monthly.
Baseline time for one weekly report before either proposed improvement.
Budget: 45 minutes
Option A targets this preparation step.
Option B proposes stable references to remove repeated matching.
Both comparisons retain this judgement stage.
Option A automates the five-minute export. Assume four hours of setup and five minutes of maintenance per month. Option B introduces stable product references into this reporting path, removing the twenty-five-minute name reconciliation. Assume eight hours of setup and fifteen minutes of monthly maintenance. Both retain the fifteen-minute interpretation stage. These alternatives are compared separately; the example does not claim that their setup work or benefits can simply be added together without overlap.
Use fifty-two runs a year, expressed as fifty-two divided by twelve runs per month. That convention avoids pretending every month contains exactly four weeks. Option A releases twenty-one and two-thirds minutes of recurring work per month before maintenance, leaving sixteen and two-thirds net. Its 240 setup minutes take 14.4 months to recover in time terms. Option B releases one hundred and eight and one-third minutes before maintenance, leaving ninety-three and one-third net. Its 480 setup minutes take about 5.14 months to recover.
The script uses exact fractions for the calculation. Over twelve months, A releases 200 net recurring minutes against 240 setup minutes, leaving a forty-minute time deficit. B releases 1,120 against 480, leaving 640 minutes, or ten hours forty minutes, ahead. These are consequences of the illustrative inputs. Unequal staff costs or a failed implementation could change the investment decision even when the time arithmetic is right. Keep those questions visible, because recovering engineering hours and making the strongest commercial choice are related but different objectives.
The easier four-hour project is not necessarily the cheaper choice over the report’s useful life. Under these assumptions, the eight-hour change recovers its larger investment sooner because it removes more recurring work. But give the report only three months before replacement and neither payback looks comfortable. The monthly saving can be calculated perfectly while the investment is still a poor decision. It needs enough future runs to repay the work already spent building it.
Stable references need more than replacing the name column. The source identity must survive display-name changes, and a controlled mapping must connect it to the destination. Unknown products should remain visible for resolution rather than take the nearest familiar label. The twenty-five-minute saving assumes ordinary repeated matching disappears while real exceptions remain discoverable. Hiding those exceptions could make the process appear faster by postponing necessary correction work, which would be a very different result from removing the repetition.
The maintenance allowance must cover the new responsibility. Someone updates mappings when source products change, checks unmatched records and verifies the report has not silently dropped them. If unknown products are common, fifteen minutes a month may be too optimistic. That is a reason to revise the inputs, not to relabel exception handling as judgement and exclude its time from the comparison. Moving work from the report preparer to an engineer still leaves somebody doing it.
Option A has its own appeal. It may be easier to reverse, require less coordination and provide a useful improvement while stable references are being negotiated. It could also reduce a stressful timed task if the file must arrive at a precise point in a busy morning. The time model does not quantify that benefit. A team can choose it for that reason, provided the explanation is explicit rather than claiming the spreadsheet proves it is the strongest hours-saving option.
Automating interpretation would be a separate proposal needing different evidence. A surprising sales or stock variance may require someone who understands its context, even when preparation and delivery can run unattended. Retaining that fifteen-minute stage makes the scope of this comparison explicit. The proposed improvements release repetitive preparation time; they do not establish that the report is ready for automatic distribution or that judgement about its unusual results is unnecessary.
Now run the same report once a month instead of weekly, keeping the setup and maintenance assumptions unchanged. Option A saves five minutes and needs five minutes of upkeep, so it has no net recurring time benefit and never recovers its setup time in this model. Option B saves twenty-five minutes, spends fifteen on maintenance and releases ten net. Recovering eight setup hours then takes forty-eight months. The attractive weekly case becomes a much weaker monthly case without changing a line of proposed automation.
Fixed monthly maintenance is deliberately simple here, not a claim about how support actually behaves. Some checks happen per run; others follow vendor changes however rarely the report is produced. Separate those costs when they affect the decision. The monthly counterexample is useful because it exposes the assumption, but estimating a real integration means finding how this one will be supported. Reusing the convenient demonstration numbers would preserve the arithmetic while losing the reason for doing it.
Observed handling time also needs a consistent definition. Record active preparation, exception resolution and relevant follow-up, not the entire interval while a file downloads if the person is doing unrelated work. At the same time, do not assume interrupted work has no cost just because it is difficult to measure. Note what was counted and retain uncertainty where the estimate is weak. Inventing a universal context-switch multiplier would create more apparent precision while making the decision harder to audit.
After a trial, measure the same activities again. If the export is faster but the file now needs manual repair, include that repair. If normalisation removes one reconciliation and creates another, record both. A baseline and a follow-up using different definitions can make a project look successful without reducing the actual burden. The purpose of a small model is to make such assumptions discussable, then replace them with evidence as the team learns, rather than defend the first forecast.
Illustrative time assumptions, calculated at52 runs/year. These are not observed client savings or cash-flow estimates.
Scroll sideways to see all columns.
| Option | Setup | Net time/month | Time payback | 12-month net after setup |
|---|---|---|---|---|
| A: automate 5-minute export | 240 min | 16⅔ min | 14.4 months | −40 min |
| B: stable references; remove 25-minute reconciliation | 480 min | 93⅓ min | ≈5.14 months | +640 min |
| A at 1 run/month | 240 min | 0 min | No time payback | Not beneficial on these inputs |
| B at 1 run/month | 480 min | 10 min | 48 months | Horizon-dependent |
Before implementing either option, establish which decision the report still supports. Retiring it could remove more work, but a quiet inbox does not show that nobody depends on it. Ask its owner to account for the decisions, recipients and continuing obligations that would disappear with the report. Someone may rely on its ordinary arrival without replying every week. That makes retirement a different proposal from shortening preparation, with its own agreement to obtain before counting the whole forty-five minutes as work the organisation can stop doing.
For this forty-five-minute baseline, keep the interpretation stage and compare the complete burdens of the two alternatives. The report’s likely lifetime, ownership of exceptions and maintainability of stable references decide whether the larger setup effort is worthwhile. Weekly, Option B recovers sooner. Monthly, it takes forty-eight months. That difference is worth knowing before choosing the smaller build simply because it starts with the most obviously repetitive five minutes.
Working on a workflow like this? Hamsa helps finance and operations teams connect their tools and handle the exceptions, starting with one workflow.
See the Payment Operations PilotPrimary sources behind this article. Living documentation may change.

Practical engineering. A human perspective.
More about Hamsa Software and the person behind it. Editorial notes.