Find the Hours Worth Automating

21 July 2026 · 2 min read

blog contents
  1. Measure before you map
  2. Frequency beats duration
  3. Follow the copying
  4. Automate the boring middle first

read

Most automation projects start with a tool somebody liked and work backwards to a problem. Start from the hours instead: for two weeks, record what the team actually repeats, how often, and how long it takes. The list that comes back is always shorter than the list people describe from memory, and the top item is almost never the one that gets complained about most.

Measure before you map

Ask a team what eats their time and you get the tasks that annoy them. Measure it and you get the tasks that repeat. These are different lists, and only the second one pays back.

Two weeks of rough logging is enough. Precision is not the point, order of magnitude is.

Frequency beats duration

A task that takes an hour once a month is sixty minutes. A task that takes four minutes but happens forty times a week is far more, and nobody ever mentions it because individually it feels like nothing.

Rank by total time, not by how painful each instance feels. The ranking is usually a surprise.

Follow the copying

Wherever a person moves the same fact from one system to another, there is either a missing connection or a missing field. Both are cheap to fix and both compound.

The tell is a spreadsheet that exists only as a waypoint between two other systems.

  • The same value typed into two places
  • A daily export that becomes a daily import
  • A message that just says a record changed
  • A report rebuilt by hand each week from the same source

Automate the boring middle first

The start and the end of a process usually involve people and judgement. The middle is routing, formatting, checking and notifying, and that is where automation is both easiest and safest.

Doing the middle first also leaves the human parts intact, which makes the change much easier for the team to accept.

questions

How long should the measuring take?

Two weeks is usually enough to see the repeats, and short enough that people actually keep it up. Longer studies produce better data that nobody acts on.

What if the team resists logging?

Make it coarse. Categories and rough counts beat precise timings, and they get filled in. The goal is ranking, not accounting.

Should we automate the worst task first?

Not usually. Start with something frequent, low risk and visible, so the team sees the benefit early. The hardest task first tends to consume the goodwill the project needs.

More on this track

  1. How to Automate Your Business Automate in this order: count where the hours actually go, fix the process before encoding it, integrate the systems that make people retype data, add AI only where the input is messy and the output gets checked, and stop when the next item costs more to automate than it saves. 29 August 2026 · 3 min read
  2. Processes You Should Never Automate Automation multiplies whatever it touches. Point it at a good process and you get leverage, point it at a broken one and you get the same breakage at speed and at scale. Four kinds of work should stay manual: anything nobody has written down, anything that is decided rather than executed, anything rare enough that the rule never stabilises, and anything where being wrong is expensive to reverse. 5 August 2026 · 3 min read
  3. What Breaks When You Automate Automation rarely fails with an error. It fails by continuing to run after the world underneath it changed: a field renamed, a rate limit hit, a supplier altering a format without telling anyone. The work is not building it, the work is noticing when it drifts. Anything running unattended needs a way to say it is unwell and a written answer for what to do about it. 2 July 2026 · 2 min read