Henry Kobutra
← All notes
Notes

Before I automate it

A worked example and a copyable worksheet for deciding whether a recurring task needs a script at all.

A recurring task is an invitation to write a script. I want to know whether the task should survive first.

The comparison that interests me is between automation and the simplest acceptable manual version. Comparing a script with a particularly awkward process gives the script too much credit. Some of the savings belong to deleting work.

You can make this decision with a sheet of paper or a spreadsheet. Bring a recent example of the task, someone who uses its output, and a rough timing of the work. You don't need an automation platform to decide whether you need automation.

A weekly handoff, before the script

Consider a hypothetical operations coordinator who prepares a weekly list of open service requests without an owner. The output is an internal handoff: a snapshot of the outstanding requests, links to the records, and a note beside any exception. Nobody changes a customer record or sends a customer message from this list.

All timings below are assumptions for the exercise, not measurements from a company. Assume the recipient needs a snapshot. If a link to a live view would do, use that instead and time the smaller task.

The coordinator currently spends 35 minutes exporting requests, filtering rows, checking status, and laying out a summary. A proposed script would make the summary automatically.

Before pricing that script, ask the recipient which parts they use. In this example, assume they need the links and exception notes, but not the formatted slide. Removing the slide cuts the task to 25 minutes. The output is less pretty and still does its job.

Next, check the source system. Assume it already supports a saved view with these conditions:

status = open
owner is empty
sort by age, oldest first

This is a capability assumed for the fictional system, not syntax to paste into a particular product. Check how your own tool represents an empty owner and whether its filters include every relevant open status.

With that view, assume the task takes 12 minutes: eight to prepare the snapshot and four to review exceptions. Test the view against a manual inspection of the source records. Include an unassigned open request that should appear, an assigned request that should not, and a closed request with no owner that should not.

At this point, writing the script has a much smaller job: save the eight minutes of preparation. It cannot claim the time already saved by removing the slide and using the existing filter.

Give the script an honest estimate

Suppose a small report script would take 180 minutes to build, test, and document. It would leave four minutes of human review each week. Budget another two minutes per week for maintenance and one for failure recovery, averaged over time. Those are planning allowances; a broken export could consume them all in one afternoon.

Item Assumed time
Manual work after simplification 12 minutes/week
Review after automation 4 minutes/week
Maintenance allowance 2 minutes/week
Recovery allowance 1 minute/week
Net saving 5 minutes/week
Initial work 180 minutes

The arithmetic is:

Weekly saving = 12 - 4 - 2 - 1 = 5 minutes
Break-even = 180 / 5 = 36 weeks

Over a 26-week planning window:
Manual = 26 * 12 = 312 minutes
Automated = 180 + 26 * (4 + 2 + 1) = 362 minutes

For this example, I'd keep the saved view and manual handoff. Automation costs more time within that window. Even over 52 weeks, the net saving is only 80 minutes. Doubling the maintenance allowance moves break-even to 60 weeks.

You can reproduce these calculations with Python 3 and the companion calculator:

python3 collection/examples/decision-review/estimate.py

Time isn't the only possible justification. A missed request could matter more than the minutes involved. If reliability is the reason to automate, define the improvement you need and test it. Don't quietly turn an assumed reduction in mistakes into a measured benefit.

Copy this into the next decision

Task and recipient:
What decision or action does the output support?
Required output, including freshness:

Can we stop doing it? Who confirms?
What can we remove or do less often?
What existing feature have we checked?
Simplest acceptable manual method:

Runs per week:
Minutes per run after simplification:
Build + test + documentation minutes:
Human review minutes per run after automation:
Maintenance minutes per week:
Recovery minutes per week:
How were these numbers measured or estimated?

Weekly saving = runs * (manual - review) - maintenance - recovery
Break-even weeks = initial work / weekly saving
If weekly saving is zero or negative, there is no time payback.
Useful lifetime of this process:

Worst plausible failure and who notices:
Manual fallback:
Owner of the automation:
Evidence required before trusting the output:
Decision: stop / simplify / existing feature / automate
Revisit when:

For the hypothetical handoff, a future trial should only generate a draft. Compare its request IDs and exception notes with the manual result. An empty report needs an explicit distinction between "no matching requests" and "couldn't read the source." Keep the saved view as the fallback, and leave sending the handoff with the coordinator.

Reopen the decision if volume grows, the handoff becomes daily, or preparation causes a demonstrated problem. Until then, the useful result is the saved view and the shorter task. There is no script to maintain.

A conversation starts somewhere

What are you
working on?

If something here connects with what you're working on, email me.

henry@kobutra.com