How to tell whether an automation saved time

Measure automation ROI as a comparison of minutes on one chore. Time the old way. Time the review the new way requires. If review takes longer than the old chore, the automation did not save time. Remove it, or shrink it until it does.

A chart of "hours saved" is a story the tool tells about itself. The comparison below is a count a founder can do with a clock and a week of real work. No model of the company is required.

Time the old chore before you turn anything on

Pick one workflow. Write the steps as they actually happen, including the waiting and the retyping. An intake that "only takes a minute" often includes finding the request, copying it into a tracker, asking one clarifying question, and filing the answer. Those minutes count. The fantasy version of the chore, the one without the interruptions, is not the baseline.

For a few real runs, write down the start and the end. Five runs will show you whether the chore is stable. If one took 4 minutes and the next took 40 because the request was a different kind of work, you do not have one chore. You have a pile. Split the pile before you measure it, or the number will be noise.

Note who does the chore. A founder's minutes and a new hire's minutes are both real, and they are not interchangeable. Saving the founder from a task only they can check is different from saving a task anyone can do. Write the name of the role next to the baseline so the later comparison stays honest.

Do this before the tool is installed. Afterward, people misremember the old way as either heroic or trivial, depending on whether they want the automation to look successful. The notes from the week before are the only baseline you will trust later.

Here is the shape of a count, labeled as an exercise, not as a client result. Suppose retyping an intake into a tracker takes 12 minutes, and you do it 8 times a week. The old cost is 96 minutes a week. That is the number the new way has to beat. It is not a promise. It is a yardstick you replace with your own clock.

Time the review, not the demo

After the automation is running, time what a person still does. Open the item, read it, fix it, and send it. Include the time spent figuring out whether the draft is wrong. That figuring is the work. A demo where someone clicks approve on a perfect example is not a measurement.

If the person keeps a draft open while they do other work, count the occupied time, not the elapsed time. A review that sits in a tab all afternoon did not take all afternoon. A review that takes 15 focused minutes did.

Write down the fixes. "Changed the date." "Deleted a sentence the customer should not see." "Rebuilt the whole thing." The third one means the automation is not saving this run. Those runs belong in the average. Dropping the bad runs is how a measurement becomes a pitch.

Use the same kind of inputs as the baseline. If you only time the easy cases, you will "save" time you never spent. Match a normal week, including the messy request.

The exercise, continued: the form now files itself, and a person spends 4 minutes checking each of the 8 intakes. Review costs 32 minutes. Against a 96-minute baseline, the week is 64 minutes lighter, if the checks are catching real issues and the sends are fit to go. If the checker spends 20 minutes untangling each bad parse, review costs 160 minutes. The automation is now the slower process. The exercise ends by turning it off.

Count a week, then decide

One lucky day is not a result. Count a week of the real chore, then a second week if the first was strange. Add the minutes. Divide by the number of runs so a single disaster does not hide in a total, and also keep the total, because a disaster that happens every Friday is part of the cost.

Put three numbers on one note:

• Minutes per run, before.
• Minutes per run, after, including review.
• Runs in the week.

The difference per run, multiplied by the runs, is the time saved or lost. Keep the unit in minutes. Translating into a dollar figure you cannot defend will make the note look more precise than it is. If you later want a money view, use a wage or a rate you already pay, and label it as that rate. Do not invent a blended cost of the company.

Watch for shifted work. Sometimes the automation saves the operator and costs the customer, who now writes a longer form, or the next teammate, who cleans a worse queue. If those minutes are yours, they belong in the after column. A saving that is actually a transfer is not a saving.

Nielsen Norman Group's 2011 research on how long people stay on web pages is a reason to keep this note short. Users often leave within 10–20 seconds and read only about a quarter of the text on a page. A ROI dashboard with twelve charts will not be read on the Tuesday you are supposed to decide. A five-line note will. The measurement should survive a busy week, or it is theater.

If review takes longer, remove it

Removal is a successful outcome of the measurement. You learned the chore was cheaper by hand. Turn the automation off, thank the experiment, and do not leave a half-connected tool sending on Tuesdays "just in case." A zombie workflow still creates review, which means it still costs the minutes you meant to get back.

Sometimes the right change is smaller than removal. The automation prepares a draft and a person sends it, but the draft includes three fields nobody reads. Cut those fields. Measure again the next week. Shrinking is allowed. Adding a second tool to watch the first tool is how a simple chore becomes a system you are afraid to touch.

If the time is saved and the mistakes are acceptable, keep it, and put a monthly reminder in the same note to retime one week. Source data changes. A form that saved time in March may cost time in June because the requests got harder. The original baseline will not warn you. A fresh week will.

Accept a small saving. Eight minutes a week is real if the chore was irritating and the review is calm. It does not justify a complicated stack. It justifies the simplest version that produces those eight minutes. Large claims from a small chore are how teams buy a platform they will not maintain.

What not to count

Do not count the hours you spent building the automation as "value created." They are a cost. If you want a fuller picture, set them beside the weekly saving and see how many weeks it takes to earn them back. If the build took a month and the saving is eight minutes a week, you have an honest, uncomfortable answer. That answer is more useful than a dashboard.

Do not count hypothetical runs of a chore you do not have yet. Measure work that already happens. A forecast of a thousand future tickets is a plan, not a result.

Do not count a feeling of modernity. The question is whether the week got lighter for the person who does the chore, without making it heavier for the customer. If you cannot point at the minutes, you do not know.

Hanabi's services include a small automation when that minute-count is the kind of case you can describe. The studio would rather build one chore that is faster to review than a system that needs its own staff.

Choosing the chore is the piece to read before you build a second one. Start AI automation with one boring workflow explains how to pick a repeated task with a clear input and output, which is the only kind of task this measurement can judge.