Not every process should be automated. Some things are better done manually. Some aren't worth the effort. Some would cost more to automate than you'd save.
Here's my framework for deciding what gets automated and what doesn't.
First filter: Frequency and volume.
How often does this happen? Daily? Weekly? Monthly?
If something happens once monthly and takes 30 minutes, that's 6 hours annually. Not worth automating. The time to build automation would exceed the time saved.
If something happens 50 times daily and takes 5 minutes each time, that's 250 minutes daily. Over 1,000 hours annually. Definitely worth automating.
My rule: If it's less than 5 hours monthly, keep it manual unless there's a compelling non-time reason to automate.
Compelling non-time reasons include: extremely error-prone, time-sensitive (needs to happen faster than humans can do it), or requires work outside business hours.
Second filter: Consistency.
Do you do it the same way every time? Or does the process change based on context?
If the steps vary significantly, automation is harder. Not impossible. But harder and potentially not worth it.
I worked with a business that manually categorized customer inquiries. Wanted to automate it. But when I watched them do it, every decision was contextual. Same keywords meant different things depending on other factors. Lots of human judgment involved.
Could have used AI to attempt this. But would have been expensive and unreliable. Told them to keep it manual.
Compare that to a different business that routed orders based on clear rules. Over $X goes to warehouse. Under $X ships from store. Specific product categories always use specific shipping. No variation. No judgment calls.
Perfect automation candidate. Built it in a day. Still running perfectly.
Consistency matters more than complexity. A complex but consistent process is easier to automate than a simple but variable process.
Third filter: Error rate and impact.
How often do mistakes happen? What's the cost when they do?
A process that's done manually 20 times monthly with zero errors? Probably fine to leave manual. Low urgency.
A process done 200 times monthly with 5% error rate and each error costs the company money or reputation? High priority for automation.
I automated invoice processing for a client. Manual process was fast. Only took 3 minutes per invoice. But errors happened 2-3% of the time. Wrong amounts. Wrong accounts. Wrong due dates.
Each error created follow-up work. Emails. Corrections. Apologies to vendors. That follow-up work cost more than the original task.
Automating reduced errors to nearly zero. Paid for itself in two months just from eliminating error correction time.
Fourth filter: Bottleneck effect.
Is this task blocking other work? Are people waiting for it to finish before they can do their jobs?
Even if the task itself doesn't take much time, if it creates bottlenecks, it's worth automating.
Had a client where one person manually approved all expense reports. Took her 20 minutes daily. Not a huge time sink for her.
But employees waited days for approval. Couldn't book travel. Couldn't order supplies. Couldn't proceed with purchases. Bottleneck affected the entire team.
Automated the approval for standard expenses under a certain amount. Flagged unusual expenses for manual review. Removed the bottleneck. Team could move faster even though the approver's time savings was modest.
Fifth filter: Technical feasibility.
Can this actually be automated with available tools and reasonable effort?
Some processes require human judgment that's hard to replicate. Some integrate with systems that don't have APIs. Some are technically possible but would require custom development that's too expensive.
I use this question to filter out projects that sound good but aren't realistic.
Client wanted to automate candidate screening for hiring. Read resumes. Evaluate qualifications. Schedule interviews with good matches.
Parts of that are automatable. Extracting data from resumes. Checking for required keywords. Scheduling interviews.
But actually evaluating whether someone is qualified? That requires understanding context. Experience that's transferable even if not identical. Red flags that might matter or might not. Too much nuance for reliable automation.
Told them we could automate parts but not the whole process. They decided that wasn't valuable enough. Fair call.
Sixth filter: Maintenance burden.
How likely is this process to change? How likely are the systems it integrates with to change?
If a process changes frequently, automation might require frequent updates. That maintenance cost can outweigh the savings.
Similarly, if the automation depends on external systems that change often, it might break regularly and need fixes.
I built an automation that integrated with a client's e-commerce platform. Worked great for six months. Then the platform updated their API. Broke the automation. Fixed it. Two months later, another API change. Broke again.
Eventually the client decided to keep it manual. Too much maintenance overhead. The platform changed too often.
Now I ask about system stability before committing to integrations. If the integration points are unstable, might not be worth automating even if everything else checks out.
Prioritization framework.
Everything that passes those filters is potentially worth automating. But you can't automate everything at once. Need to prioritize.
I rank by ROI. Time saved plus errors prevented divided by implementation cost.
High-frequency, high-error-rate, simple integrations rank highest. Those are quick wins. Do those first. Build trust. Show value.
Then tackle the more complex stuff. Lower frequency but high impact. Or higher implementation cost but still positive ROI.
Automate in phases. Start with the obvious candidates. Learn what works. Build momentum. Then expand to more complex automation.
What I don't automate.
Client-facing communication that needs personalization. Even when it's repetitive. Templates are fine. Full automation usually isn't.
Strategic decisions. Obviously. But also tactical decisions that require context I can't easily capture in rules.
Anything where the error cost is catastrophic and the error rate can't be reduced to near-zero. Some things need human oversight even if they're tedious.
Processes that are in flux. If you're still figuring out the right way to do something, don't automate it yet. Stabilize first. Then automate.
Things that happen rarely. Unless there's a non-time benefit. Otherwise not worth the effort.
The framework isn't rigid.
Sometimes I bend the rules. Sometimes a client really wants something automated even though my framework says no. If they understand the trade-offs and still want it, fine.
Sometimes I automate things with modest ROI just to learn new technology. Professional development has value even if the project itself is marginal.
But the framework catches most bad automation ideas. Keeps me focused on work that actually delivers value. Keeps clients happy because they're not paying for automation that doesn't justify its cost.
That's how I decide. Not perfect. But works pretty well.