Every back-office automation pitch eventually gets asked the same question by whoever controls the budget: what is this actually worth? Most of the time the honest answer is that nobody has counted, because back-office work is structured to be hard to count. It is spread across dozens of people in amounts too small for any one person to defend in a budget meeting. A four-minute approval does not show up on anyone's dashboard. A password reset does not get its own line item. So the case for automating it gets made on vibes, a vendor's demo, or whoever complained loudest this quarter, and a case built that way is the first one cut when the budget tightens.
We build the business case differently: count the work first, in units small enough to be honest, then decide what is worth automating and in what order.
Start by counting, not by pitching
The exercise is mechanical and takes less time than most teams expect. Pick one function, usually finance or a shared-services team, and log every recurring task for a single week: approvals routed by email, invoices matched by hand, reports rebuilt from several exports, access requests worked through a queue, documents retyped from a PDF into a system of record. Nothing on that list is individually worth a project. Together, the list is worth a real decision.
The count matters because it is the only thing that survives contact with a skeptical CFO. "We think this will save time" does not survive that meeting. "Here are 40 tasks we logged in finance last week, and here is what each one costs to do by hand" does.
What belongs in the count, and what does not
Three filters keep the count honest rather than optimistic:
Volume, not visibility. A task done constantly is worth automating even at a modest saving per instance, because the saving compounds every week. A task done rarely is usually not worth the build cost, no matter how annoying it is the one time someone has to do it.
Consistent pattern, not judgment. Approval routing, document matching, and access provisioning follow describable rules. A task that depends on a person weighing context case by case is a worse first candidate, whatever its volume, because getting it wrong quietly is more expensive than the manual version.
Few systems touched, not many. A task that already requires reconciling three separate tools by hand is a sign the underlying workflow is broken, not a sign it is ready to automate. Automating a broken handoff just makes the mess move faster.
Finance work tends to clear all three filters more often than most functions: invoice matching, reconciliation prep, and variance reporting are high-volume, rule-governed, and usually contained inside one or two systems. That is a structural reason finance automation consulting engagements often start in finance specifically, not a claim that finance is uniquely deserving.
Why this is a sequencing decision, not just a savings decision
Once a function has an honest count, the temptation is to rank tasks by time saved and start with the top of the list. That ranking misses the question that actually matters for a mid-market business without a large internal automation team: what does this task feed into, and does automating it first make the next one easier or harder?
Automating how an invoice or an access request enters the system first, before anything downstream of it, means every later automation inherits clean, structured data. Automate a downstream report first, on top of the same inconsistent inputs it has always had, and the automation just produces a faster, still-wrong number. The order the work gets done in changes what each dollar of the build buys.
Governance is part of the case, not an afterthought to it
A business case that stops at "here is what we will save" and skips "here is who owns this once it runs" tends to look worse a year later than the spreadsheet promised. Every automated approval, reconciliation, or report needs an owner, a defined tolerance for what an acceptable output looks like, and a way to catch it quietly producing a confident wrong answer instead of an obvious error. That governance line item belongs in the business case from the start, not bolted on after the first incident.
Where this fits for a mid-market team
A single function with a handful of candidate tasks can usually run this count and this filter on its own. It gets harder once a mid-market business is not deciding on one task but trying to sequence a dozen of them across finance, operations, and the back office at once, where the downstream dependencies span systems no one person owns end to end. That is the point where outside judgment on AI implementation earns its place: building the count, applying the same filters across every candidate function, and sequencing the work so the first automation makes the tenth one cheaper rather than harder.
We put this into two places on the site: what we automate in the back office walks through the specific task categories, and what changes in finance covers the same exercise for reconciliation, matching, and reporting work specifically. If you are looking at a long list of back-office or finance tasks and no confident way to rank them, that ranking is worth doing properly before any tool gets evaluated. Start a conversation.