Automation saves the hours. Deciding where they go is still your job.
Decide where the freed hours go before you build the automation. Write it down, name the person, and pick the number that should move.
Most owners skip this step. They automate to get time back, and often they get it. A quarter later the pipeline is the same size, the owner is still at the desk at seven, and the verdict is that the automation did not pay. Usually it did. The hours arrived and then went nowhere in particular.
This blog has covered how reading every AI draft forever eats the time an automation was bought to save, and how a pilot can work and then fade back to the old way. This post is about the automation that works, stays in use, and still changes nothing.
Where the saved hours actually go¶
Saved time has no default destination. It drains away, and nobody notices, because nothing broke.
It drains in three ways. Work expands to fill the gap: a task that took twenty minutes now takes thirty, because there is room. Spare minutes go to whatever is loudest, which is usually the inbox, a small favour or a question from down the hall. And an hour saved in five-minute pieces across a week is never seen as an hour. Nobody sits down with it. It is gone before anyone counts it.
Hours saved are the input, not the result¶
The hours are what the automation produces. The result is the one thing those hours were meant to buy.
A result is something you can point at. More quotes sent each week. Invoices out the same day the job closes. The owner out of the office one afternoon a week. If you cannot name the result, the hours pick their own. They usually pick email.
A consulting firm that got its five hours back¶
A six-person consulting firm automates its meeting notes and follow-up emails. The notes are written for the team, the follow-ups arrive as drafts for a quick check, and the team gets back roughly five hours a week.
The owner means that time for winning new work. But nobody is named to do it, and no number is set. Three months on, the firm sends the same number of proposals as before. The five hours went into internal email and meetings that run a little longer. The automation works. The decision was never made.
Write one line before anything is built¶
The fix is one sentence, written before the build starts:
This automation frees about [hours] a week. They go to [named task], owned by [person], and [one number] should move.
For the consulting firm, the line reads: "This frees about five hours a week. They go to writing proposals, owned by the senior consultant, and proposals sent per month should go from four to six."
I would decide where the hours go before I approve the build, not after. Once the time has drained into the week, getting it back means taking something away from someone. That is a harder conversation than writing one line up front.
This line does not guarantee the number moves. It does make it obvious when it has not.
The ninety-day check: moved, moved on purpose, or leaked¶
Put a date about ninety days out in the calendar, with the owner of the line. On that day, ask three things:
- Did the number move? If yes, keep going, and write the line for the next automation.
- If not, did the hours go somewhere else on purpose? Sometimes a better use appears. That is fine if someone chose it. Rewrite the line to match.
- Or did they leak? If nobody can say where the time went, it leaked. Reassign it: pick the task again, name the person again, and block the hours in their calendar so the inbox cannot take them first.
The check takes ten minutes. Skipping it is how a working automation gets written off as a failure.
Hours without a job find one.
Keep exploring¶
If you want help writing the one-line decision for an automation you are planning, start the AI Readiness Audit or contact FIT.