Automate it or staff it: deciding when a workflow is worth automating

Reference article · 5 min read

Most automation decisions in government get made in the wrong order. Someone sees a demonstration, the workflow looks like a match, and the cost question turns into a procurement formality after the decision is already settled. The arithmetic that should come first is not complicated, but it has to include the costs that never appear on a quote: the integration work, the exceptions a machine will not handle, and the person who owns the automation for as long as it runs.

What follows is a way to work that arithmetic before you commit to a pilot. The goal is not to argue against automation. It is to be able to explain, in a budget hearing or a council meeting, why this workflow and not another one, and what the agency gets in return.

Measure the workflow you actually have

Start with observation rather than description. Ask four questions and get real answers.

• Volume. Transactions per year, and how they distribute across the year. A permit process that handles most of its volume in a six week window behaves very differently from a steady queue.
• Handle time. Time the work, or sample it. Staff estimates of their own task duration tend to drift, usually in the direction of the worst case.
• Exception rate. What share of cases leave the standard path and require judgment, a phone call, or a supervisor. This number drives more of the outcome than anything else.
• Ownership. Who touches the process, in which systems, and under what authority. Steps that cross department lines are where integration cost hides.

Count the full cost, not the license

The build price is usually the smallest line. A defensible cost estimate includes:

• Build or configuration effort, whether by staff, a contractor, or a vendor professional services team.
• Recurring fees, and the unit they are priced in. Per user, per transaction, and per automated process scale very differently as volume grows.
• Integration and review. Credentials, interface work against the system of record, security review, privacy and records review, and accessibility review where public interfaces are involved.
• Exception handling. Automation moves work rather than removing it. Someone monitors the queue, resolves failures, and handles the cases that fall out.
• An ongoing owner. Every automation is a small system that breaks when an upstream form, screen, or data element changes. If no named person has budgeted time to maintain it, the automation has a shelf life measured in months.
• End of life. If the underlying application is scheduled for replacement, the automation is replaced with it.

Value the benefit in fully loaded hours

Use the fully loaded hourly rate, not base salary. Your budget office maintains a fringe and overhead rate for exactly this purpose. Ask for it and use the agency's own figure so the number survives review.

Then apply three discounts. Count only hours the automation genuinely removes, not fractions of a minute spread across many small tasks, because those rarely convert into capacity anyone can use. Subtract the residual work: review, monitoring, and the exception queue. Finally, separate cash savings from service improvements. Shorter cycle time, fewer errors, a smaller backlog, and more timely reporting are real benefits, and they belong in the case, but label them clearly rather than converting them to dollars with an assumption no one can defend.

Set a payback horizon the budget can live with

Pick a horizon tied to the expected remaining life of the systems involved, and state it explicitly. Then test it. Halve the volume assumption, double the exception rate, and add a maintenance allowance. If the case only works under optimistic inputs, it is not a case.

Fund source matters as much as total cost. One time build money and recurring subscription money frequently come from different places, and grant terms often treat implementation costs and ongoing operating costs differently. Program rules vary and change, so confirm allowable costs with the grant administrator or your finance office before assuming a recurring fee is covered.

Know when hiring, contracting, or deleting wins

• Delete or simplify first. Removing a redundant approval, retiring a form field nobody uses, or eliminating a report no one reads costs nothing to license and nothing to maintain.
• Low volume, high variability. Work that is irregular and judgment heavy is usually cheaper to cross train for than to encode.
• Seasonal spikes. Temporary staff or a service contract can absorb a predictable annual surge without a permanent technical dependency.
• Policy driven steps. If a rule or statute requires the step, changing the rule may be the cheaper intervention. Confirm the requirement with counsel rather than assuming it.
• Unstable processes. Automating a process that is still changing locks in a design you have not finished arguing about.

What to ask vendors and what to require

Ask for total cost across the full contract term, including renewal escalation and the price of growth in volume. Ask what happens when the upstream system changes, who is responsible for the fix, and whether that work is included. Ask what skills the agency needs in house to maintain the configuration.

In the contract, require exportable configuration and data at exit, transition assistance, and acceptance criteria tied to measured throughput or handle time rather than a go live date. Scope any pilot to one workflow with a defined end and a decision point.

Be honest that savings arrive as capacity

In most agencies, automation does not reduce headcount. It absorbs growth, shrinks a backlog, or moves staff to work that is currently not getting done. Say that plainly in the request. Then commit to something specific and measurable: a backlog target, a processing time, or a function that becomes staffed. Record the baseline before go live, because without it the benefit becomes unprovable and the next request is harder to make.

HQT works with state and local agencies on process assessment, systems engineering, and automation design.

Frequently asked questions