How To Document Hours And Dollars Saved (Before And After)

Documenting what an automation saved means capturing two simple snapshots, the task before it was automated and the same task after, then turning the gap between them into hours and dollars. You write down who did the work, how long it took, how often it ran, and what it cost in loaded labour. You take the same reading once the system is live. The difference is your saving. It is the difference between “it feels faster” and a number you can put in front of yourself and decide on.

The Bottom Line

• “It feels faster” is not a number you can make decisions with. A before-and-after snapshot is.
• Capture the before: who did the task, how long, how often, the error rate, the loaded cost.
• Take the same reading after it goes live, then turn the gap into hours and dollars per year.
• Keep it honest. A real, modest number you trust beats an inflated one you cannot defend.

Why “It Feels Faster” Isn’t Enough

After an automation goes in, the usual verdict is a shrug and a “yeah, it’s better”. Better is not a number. It will not tell you whether the build paid back, which task to automate next, or whether the time you got back is worth what you spent. A vague good feeling fades, and six months later you cannot remember whether it actually moved the needle.

This matters most when you are deciding what to do next. The whole model is to automate one task, prove it, then expand a layer at a time. You cannot prove anything without a measurement, and you cannot measure a saving if you never wrote down what the work used to cost. The before snapshot is the part everyone skips, and it is the part that makes the rest possible.

The good news is that this is not a finance project. It is a short, honest before-and-after you can capture on one page. Done once per automation, it turns a pile of “feels better” into a stack of real results you can point to. If you want the deeper version of the maths, the payback math before you sign sets it up before the build, and this is how you confirm it afterwards.

The Before Snapshot

The before snapshot is a quick reading of the task while a human still does it by hand. Take it before anything is automated, because once the system is live the old cost is gone and you are guessing. Five things capture it: who does the task, how long it takes each time, how often it runs, how often it goes wrong, and the loaded cost of the person doing it.

Be specific. “Reconciling the bank takes a while” is useless. “The bookkeeper spends about three hours every Friday, and roughly one in ten transactions needs a correction” is a baseline you can compare against. You do not need a stopwatch and a spreadsheet of timestamps. A careful estimate from the person actually doing the work is enough, and it is usually close.

Use a loaded hourly rate, not bare salary. The real cost of an hour is the wage plus super, plus the tools that person needs, plus the on-costs of employing them. A task that looks cheap at a headline salary is more expensive once you load it properly, which is exactly why automating it pays back faster than people expect. Write the loaded rate down once and reuse it.

The After Snapshot

The after snapshot is the same five readings, taken once the automation has been live long enough to settle. Give it a few weeks. The first days of anything new are messy, and you want the steady-state number, not the launch wobble. Then read it the same way: who touches the task now, how long it takes them, how often, and how often it still needs a correction.

The shape of the answer is usually a flip, not a deletion. The bookkeeper who spent three hours reconciling now spends twenty minutes approving a queue the system has already coded. The task did not vanish. It changed from doing every step by hand to reviewing and signing off, because anything that touches money stays human-in-the-loop. Capture the new, smaller human cost honestly rather than pretending it dropped to zero.

Watch the error rate too, because it often falls further than the hours. A system that codes the same way every time does not have an off day, mistype a figure, or forget a step when it is busy. Fewer corrections means less rework downstream, and rework is a cost that rarely shows up in anyone’s estimate but quietly eats real time.

Turning The Delta Into A Number

The delta is just the before minus the after, in two currencies: hours and dollars. Hours first. If the task ran fifty-two times a year and you saved roughly two and a half hours each time, that is around a hundred and thirty hours back in a year, from one task. Dollars next: multiply those hours by your loaded rate to get the annual saving.

Here is an illustrative example, not a client result, so use your own numbers. Say a weekly task took three hours and now takes twenty minutes, a saving of about two hours and forty minutes a week. Across a year that is roughly a hundred and forty hours. At a loaded rate of, say, 60 AUD an hour, that is in the region of 8,000 AUD a year, freed from one repeating job. Set that against the build and run cost and you can see, plainly, whether it paid back and how fast.

Then add the second-order wins the formula misses, even though you will not put a precise figure on them. Faster turnaround, fewer dropped balls, work that gets done on time instead of late, and owner hours you got back. The biggest one rarely fits in a cell on a page: the ability to step away for two weeks and have nothing break. Note these alongside the hard number so the picture is complete.

Presenting It Cleanly

Keep the write-up to a single page anyone can read in a minute. A short before column, a short after column, and a one-line result at the bottom: the hours saved a year, the dollars saved a year, and the change in errors. That is the whole artefact. You are not writing a report, you are capturing a result you can defend and reuse.

This small record does three jobs. It tells you whether the last build was worth it. It makes the case for the next one, because “the last automation gave us back a hundred and forty hours” is a far better argument than “the last one felt good”. And if you ever need to justify the spend to a partner or a board, you have the number ready instead of a memory.

Do it once per automation and the records stack up into something genuinely useful: a running picture of how much bandwidth you have clawed back, task by task. That picture is the point of the whole exercise, the away-from-desk autonomy you are building one proven task at a time. For the ongoing version that watches the numbers for you, see how to measure ROI after it goes live.

Frequently Asked Questions

Do I Really Need A Before Snapshot, Or Can I Work It Out Afterwards?

Take it before. Once the automation is live, the old manual cost is gone and you are reconstructing it from memory, which tends to flatter the result. A five-minute reading while a human still does the task, how long, how often, the loaded rate, is far more honest than a guess made later. The before snapshot is the cheapest, most valuable five minutes in the whole exercise.

What Hourly Rate Should I Use?

A loaded rate, not bare salary. Take the wage, add super, the tools that person needs, and the on-costs of employing them. The loaded figure is the true cost of an hour of their time, and it is what makes the saving real. Using bare salary understates the saving and makes good automations look worse than they are. Set the loaded rate once and reuse it across every task you measure.

Won’t The Numbers Be Rough Estimates Rather Than Exact?

Yes, and that is fine. You are not auditing, you are deciding. A careful estimate from the person doing the work is accurate enough to tell a clear win from a marginal one. The risk is not imprecision, it is inflation. Keep the numbers honest and modest, and a rough-but-real result will serve every decision you need to make far better than a precise-looking fiction.

What If The Task Did Not Disappear, Just Got Smaller?

That is the normal outcome and you should record it as such. Most automations flip a task from doing every step to reviewing and approving, because anything touching money or clients stays human-in-the-loop. Capture the new, smaller human cost rather than claiming the task went to zero. An honest “three hours became twenty minutes” is a strong result, and it is one you can stand behind.

If you have automations running and no idea what they actually saved you, the fix is a simple before-and-after you can capture on one page and reuse for every build. We help you set the baseline before we build, so the result is a number you trust rather than a feeling, and so the next decision is an easy one. Get In Touch.