Choosing What to Automate First: A Practical Framework

Most businesses have dozens of candidates for automation. Invoice processing, expense approvals, customer onboarding, lead scoring, report generation, scheduling, data entry. Teams often pick the impressive-sounding one: "Let's automate our customer intelligence pipeline" or "Let's build an AI system to predict churn."

Then they spend months building, and after it's done, it saves a few hours a week while the real bottleneck—the process that actually wastes the most time or causes the most friction—goes untouched.

Picking the right process to automate first matters because your first automation shapes how your team thinks about automation, what they learn, and whether they trust the process going forward. Start with the wrong process and they'll lose confidence. Start with the right process and you build momentum.

The framework: repetitive, error-prone, time-consuming

Three characteristics identify the best automation candidates:

Repetitive: Does it happen the same way every time, multiple times per week or more? A process that happens once a year isn't worth automating. A process that happens 100 times a year is.

Error-prone: Do mistakes happen? Do people have to double-check the work? Do errors create downstream problems that someone else has to fix? Automation is good at doing the same thing consistently. Processes where consistency matters most are good candidates.

Time-consuming: How much total time does this process consume? Add up the time across the team. If one person spends 5 hours a week and two others spend 2 hours each, that's 9 hours per week—almost a full-time employee worth of work.

A process that's repetitive but only takes 30 seconds each time isn't worth automating. A process that's time-consuming but happens once a month isn't a priority. A process that's error-prone but only affects one person isn't as impactful as one that affects the whole team.

The best automation candidates hit all three: they happen regularly, they're prone to mistakes, and they consume meaningful time.

Scoring your candidates

Make a list of processes you're considering automating. Score each one:

Repetition: How many times per year does this happen?

• Less than 20 times/year: score 1
• 20-50 times/year: score 2
• 50-200 times/year: score 3
• 200+ times/year: score 4

Error rate: What percentage of executions have mistakes that require rework?

• Less than 5%: score 1
• 5-15%: score 2
• 15-30%: score 3
• More than 30%: score 4

Time per cycle: How long does one execution take, multiplied by how many people do it?

• Less than 30 minutes/week total: score 1
• 30 minutes to 2 hours/week total: score 2
• 2-8 hours/week total: score 3
• More than 8 hours/week total: score 4

Total score: Add them up (max 12). Processes scoring 10-12 are excellent candidates. 8-9 are good. Below 8 are lower priority.

But don't stop at scoring. Consider also:

Stability: Has this process been the same for the last six months? If it changes frequently, automation is harder. Stable processes are better candidates.

Clarity: Does everyone do it the same way? If three people do it three different ways, you need to standardize first.

Impact: If this process automates, who benefits? If it only affects one person, impact is lower. If it affects ten people, impact is higher.

Implementation difficulty: Some processes are easy to automate (collect data from a form, send an email). Others require complex logic or API integrations. Start with the easy ones.

Dependencies: Does this process depend on manual inputs from other people? If so, automation is harder.

Avoid these common mistakes when choosing

Optimizing for impressive over impactful: "We'll build an AI system to predict customer churn" sounds impressive. "We'll automate expense report data entry" sounds boring. But if data entry is consuming 20 hours a week and churn prediction only affects once-a-quarter strategy, expense entry is the better starting point.

Picking something nobody fully understands: If you're not sure exactly how the process works, it's not ready to automate. This is a signal to document first, automate second.

Picking something that rarely works right anyway: If the current manual process is so broken that nobody trusts it, automating it won't help. Fix the process first, then automate.

Picking something that requires stakeholder buy-in you don't have: If the process crosses departments and you don't have agreement on how it should work, automation will create conflict. Build consensus first.

Picking something that's currently a person's entire job: If automating it means that person has no job, you have organizational friction to solve before you automate.

Picking the most technically interesting option instead of the most business-impactful: It's tempting to automate something because it involves cool technology. Resist that. Pick based on impact, then figure out the technology.

The process of choosing for your team

Bring together the people who do these processes and their managers. Go through the candidate list. Ask:

1. Which of these processes frustrates you most?
2. Which one would give you back the most time if it were automated?
3. Which one creates the most headaches when it goes wrong?
4. Which one could we automate without disrupting how people work?

Listen to their answers. They know what's actually painful. They also know what's stable enough to automate and what will break if you automate too soon.

Have them score candidates independently. Then compare. Disagreements are interesting—they reveal different priorities. The processes that score highly and have consensus are your best bets.

Starting with a quick win

Your first automation should be something that works fast and builds confidence. This means:

• Simple logic, not complex decision trees
• Stable process that hasn't changed in months
• Clear success metrics
• Works with tools you already have

An example quick win: automatically tagging incoming support tickets by topic using keywords. This takes a few hours to set up (just define keywords for each topic), works immediately, and saves 20 minutes per day of manual tagging. People see the value fast.

A harder first project: building a system to score and route sales leads. This requires understanding lead quality, defining what makes a lead "high quality," integrating with your CRM, and training the system. It's valuable but takes longer to implement and validate.

For your first project, pick the quick win. Build it, show results, get team confidence. Then tackle the bigger projects.

Scaling from your first automation

After your first success, use what you learned to pick the second project. You now know:

• How long implementation actually takes
• How much value is realized and how fast
• Whether your team trusts automation
• What implementation tools work for you
• What kinds of processes are suitable

Use this to get better at picking. Your second automation will move faster and deliver more value than the first.

Most teams find that after automating their first few high-impact processes, they develop a sense for what's a good candidate. They stop overthinking it and just start building.

---

FAQ

How do I know if a process is ready to automate? It's been stable for at least six months, everyone does it the same way (or you've standardized it), you can describe it clearly, and it's not about to change.

Should I automate across the company or start with one department? Start with one team or department. You'll learn faster, fail smaller, and be able to adjust before scaling.

What if people are worried that automation will replace them? Address this directly. Automation usually eliminates tedious parts of a job, freeing time for higher-value work. It rarely eliminates entire roles. Help people see that automating data entry means more time for strategy and customer work.

Can I automate multiple processes at once? Not recommended for your first few. Do one, learn, succeed, then move to the next. Multiple simultaneous projects create confusion and lack of focus.

What if there's disagreement about which process to automate? Use the scoring framework. It makes the decision less political and more data-driven. If disagreement persists, pick the one with highest score and commit to it for a defined period. You can always do the other one next.

How do I handle processes that cross departments? Involve representatives from each department in the selection and design. Automation that works for one department but breaks another department's workflow creates resentment. Get buy-in from all stakeholders.

Is it better to automate or optimize manually? Sometimes optimizing manually is faster. If a process takes 2 hours a month, spending two weeks building automation might not make sense. Use the scoring framework to compare the effort and payoff.

What if automation would require changing how people work? That's fine. Sometimes the new way is better. But change management matters. Give people time to adjust, support the transition, and show them the benefit.

Can I automate a process if I don't fully understand why it exists? No. Understanding why a process exists (what business need it serves) helps you automate it correctly. Ask why before you automate.

How long should I wait after implementing automation before evaluating if it worked? At least one month. Give people time to learn the new system and for any issues to surface. After a month, you have enough data to see if it's working.

What's the most common reason automation projects fail after choosing the right process? Usually it's poor execution—the process wasn't actually standardized before automating, or the system was designed without input from the people who use it. Start with a good process choice, but don't skip the implementation work.