When should we consider automating a process, and how do we know if a process is ready for automation?

Recently our company approved budget for process automation, and my team is eager to start. We’ve identified several candidates, including our invoice processing workflow, which is currently handled by three people and takes about two weeks from receipt to payment. However, I’m worried we might be putting the cart before the horse. The invoice process has a lot of manual steps, but it also has tons of exceptions-different invoice formats from different vendors, occasional missing line items, and various approval workflows depending on the department. I’ve heard that you should map and optimize a process before automating it, but I’m not sure what “ready for automation” actually looks like. Should we automate now and optimize later, or do we need to get the process perfect first? How do I evaluate whether a process is a good automation candidate, and what steps should we take before we start building automation workflows?

From a finance perspective, I look at the cost-benefit of optimization versus automation. If the process is stable but inefficient, optimization might deliver 20-30% improvement. Automation on top of that could deliver another 40-50%. But if you automate a chaotic process, you might only get 10-15% improvement and introduce new risks. For your invoice workflow, calculate the cost of the current process-labor hours, error correction, late payment penalties. Then estimate the cost of optimization (process redesign, vendor negotiations) versus automation (software, implementation, maintenance). In most cases, optimization is cheaper and lower-risk, so do that first. Once the process is stable and standardized, automation becomes a straightforward ROI decision. Measure baseline metrics before any changes so you can quantify the impact of each phase.

Don’t forget the human side of automation readiness. Even if a process is technically ready, if your team isn’t prepared for the change, automation will fail. I’ve seen automation projects stall because staff resisted the new system or couldn’t adapt their workflows. For your invoice process, involve the three people currently handling it in the mapping and optimization phases. Get their input on what’s painful, what could be standardized, and what should remain manual. When they help design the improved process, they’ll be more willing to adopt the automation later. Also, plan for training and transition support. Automation isn’t just a technology project; it’s a change management project. If you don’t prepare the people, the technology won’t deliver the expected benefits.

Automating a poorly designed or unstable process amplifies existing problems rather than solving them. The best practice is to map, analyze, and optimize the current process first, then identify automation opportunities within that improved workflow. This prevents automating workarounds, exceptions, and inefficiencies that should have been eliminated during optimization.

Processes ready for automation typically have high volume, repetitive manual steps, clear decision rules, and low exception rates. In your invoice example, the high volume and repetitive data entry make it a candidate, but the numerous exceptions-format variations, missing data, variable approvals-suggest you should first standardize invoice formats, establish clear validation rules, and streamline approval workflows. Once the process is stable and exceptions are handled systematically, automation becomes straightforward.

Measure baseline metrics before optimization: cycle time, error rate, cost per invoice, late payment penalties. Then optimize the process-reduce exceptions, standardize inputs, simplify decision logic-and measure again. Only after you’ve achieved a stable, optimized process should you automate. This phased approach ensures you’re automating an efficient process, not a broken one. It also helps you quantify the value of each phase: optimization might cut cycle time by 30%, and automation on top of that might cut it another 40%. Stakeholders appreciate seeing incremental progress rather than waiting months for a big-bang automation that may or may not deliver. Engage the people who perform the process throughout-they know where the real pain points and exceptions are, and their buy-in is critical for successful automation adoption.

Never automate a broken process-you’ll just scale the problems. I learned this the hard way when we automated our expense approval workflow without mapping it first. We automated all the manual handoffs and data entry, but we also automated the workarounds and exceptions that existed because the original process was poorly designed. The result was faster chaos: approvals got stuck in automated loops, exceptions required manual intervention anyway, and we ended up with a more complex mess than before. Now I always map and optimize first. For your invoice process, map the current state, identify waste and bottlenecks, then redesign the process to eliminate exceptions where possible. Only then do you automate the improved process. This takes longer upfront but saves massive rework later.