How to Measure the ROI of an Automation (the Ledger We Use)

Ask a vendor what an automation saved and you will usually get a number with no history behind it. Ask how the number was made and the conversation gets vague. That is the problem with most ROI in this field: the claim arrives before the measurement.

This is the method we use on every engagement at Civic Dialog, whether a client's team builds the automation in a cohort, we build it with them in CoBuild, or we run it for them under a Fractional CAIO agreement. It is not complicated. It is just done in the right order.

Why most ROI claims fail

Three habits produce numbers nobody can defend.

• No baseline. The process was never timed before the automation existed, so the "before" is an estimate made after the fact, usually by the person who wants the project to look good.
• National averages. Hours are valued at a figure from a survey rather than what the organization actually pays the person who did the work.
• Counting hours nobody gets back. If the automation saves six hours a week but the person still works the same week on the same tasks, the organization saved nothing yet. The hours have to be reallocated, or headcount has to change, before the saving is real.

A number built on any of these is a guess. A guess is not a result.

The four steps

1. Baseline

Before anything is built, time the process as it runs today. Who does it, how often, how long each instance takes, and what an hour of that person costs the organization. The last figure is the fully loaded hourly cost: salary plus benefits and payroll taxes, divided by working hours. Most finance leads can produce it in five minutes.

Time at least ten real instances, not one. Processes have a tail: the invoice with a missing PO number, the intake form filled out wrong. The tail is where the hours hide.

2. Build

The automation goes live against that baseline. Nothing counts until it runs in real work, on real records. A demo does not count. A pilot on sample data does not count.

3. Log

Every run is logged: when it ran, what it processed, and whether a human had to intervene. Hours saved per run come from the baseline, not from a fresh estimate. Interventions are subtracted at the same hourly rate.

Revenue is stricter. If an automation generates revenue, for example a registration flow that lets an organization sell seats it could not process before, revenue counts only when the money is collected. Not booked. Collected.

4. Report

Once a month, the log becomes a ledger: the baseline, the runs, the hours returned, the dollars returned, and the cumulative total. For a Fractional CAIO client this arrives with the monthly agreement. For a cohort it is presented at demo day. For CoBuild it is the handover report. The arithmetic is the same in every case, and the client can check it.

A worked illustration

The figures below are an illustration, not a client's numbers.

Suppose an operations coordinator spends six hours a week routing inbound requests from a web form into the right queues, chasing missing fields, and updating a spreadsheet. Fully loaded, that coordinator costs the organization $38 an hour.

An intake automation classifies each submission, fills the queue, flags the incomplete ones, and updates the sheet. After a month in production, the log shows the coordinator now spends about one hour a week handling the flagged exceptions. Interventions cost 52 hours a year; the automation returns 260.

Notice what the illustration does not include: "improved morale," "faster response times," or "strategic focus." Those may all be true. They go in a separate list of observed benefits, not in the ledger, because they cannot be checked.

The ledger format

One row per automation, one column per month. The columns that matter:

• Process and the person who owns it.
• Baseline: hours per week and the hourly rate, with the date the baseline was taken.
• Runs this month and interventions this month.
• Hours returned this month and cumulative.
• Dollars returned this month and cumulative.
• Revenue collected, if the automation generates any.
• Cost to run this month, so the net is visible on the same line.

A spreadsheet is fine. The cohort portal has an ROI tracker that does this for participants, but the format matters more than the tool.

Common mistakes, and the fix for each

Valuing hours at a national average. Use the organization's own loaded rate for the person who did the work. If three people at different rates share a process, weight it.

Forgetting maintenance. Every automation needs attention when the upstream tool changes a field or a policy shifts. Put the cost to run on the ledger so the net is honest.

Reporting once. A single triumphant number at launch is marketing. A monthly ledger is measurement. Processes drift; the log catches it.

Counting the same hour twice. If two automations touch the same person's week, baseline them separately and make sure the returned hours do not exceed the hours the person actually had.

What this looks like in an engagement

In a cohort, participants baseline their own process in week three and present the result at demo day in week twelve, with a control plan naming who owns the automation and how it is monitored. In CoBuild, the baseline is taken at the scoping call and the log is part of the handover. Under the Fractional CAIO agreement, the monthly ledger is what the monthly fee buys, alongside hosting and changes.

If you want to see the method applied to one of your processes, a free Lunch & Learn is the easiest way to start. Bring the process that eats your week; we will baseline it together in the room.