Which Processes to Automate First: A Simple Scoring Method

The processes to automate first are the ones that happen often, follow clear rules, annoy the people doing them, and cause limited damage when a mistake slips through. You don't need a maturity model or a six-week discovery engagement to find them. You need a spreadsheet, four scoring questions, and an honest hour with the people who actually do the work. This post walks through that method, shows the math on a realistic example, and covers the traps the score won't catch on its own.

Why the First Automation Project Matters More Than the Tenth

Your first automation project sets the political weather for every one that follows. If it ships, saves visible time, and doesn't break anything, the second project gets approved in a hallway conversation. If it drags on for eight months and quietly dies, "automation" becomes a dirty word in your company for two or three years.

That's why picking the first process is not primarily a technical decision. It's a portfolio decision. You are choosing the project most likely to build trust, not the project with the biggest theoretical payoff. The biggest payoff is usually attached to your messiest, most political process, and that is exactly the wrong place to start.

We've watched companies invert this. They go after the whale first, usually because an executive read something about AI transforming their industry. The whale project touches four departments, two legacy systems, and a decade of undocumented exceptions. It stalls. Meanwhile, the boring project that would have saved a coordinator ten hours a week sits untouched, because it wasn't exciting enough to fund.

Start boring. Boring ships.

The Four Questions Behind the Score

For every candidate process, ask four questions and score each answer from 1 to 5.

Frequency. How often does this happen? A task performed forty times a day scores a 5. A task performed once a quarter scores a 1, no matter how tedious it is. Automation cost is mostly fixed; savings scale with volume. This is the single most common reason automation projects fail to pay back: someone automated a rare task because it was irritating, not because it was frequent.

Rule clarity. Could you write down the decision logic on one page, and would two different employees follow it the same way? "If the PO number matches and the quantities are within tolerance, approve it" scores a 5. "Use your judgment about whether the customer seems upset" scores a 1. Be suspicious of your own optimism here. Sit next to someone doing the task and count how many times they make a call the procedure doesn't cover.

Pain. How much does this task cost in time, morale, and delay? A dispatcher re-typing the same work order into three systems is pure pain: slow, error-prone, and soul-crushing for a person you'd rather have solving actual problems. Pain also predicts adoption. People eagerly adopt automation that kills a task they hate, and quietly sabotage automation that touches a task they secretly like.

Risk of error. What happens when the automation gets one wrong? Mis-filing an internal document scores a 5 (low risk, easily fixed). Sending a wrong-priced quote to your biggest customer scores a 1. Note that risk is not a reason to avoid automation forever. It's a reason to add a human review gate, where the system does the work and a person approves it before anything leaves the building. But for your first project, prefer processes where even an unreviewed error is survivable.

Add the four numbers. Anything scoring 16 or higher is a strong first candidate. Anything under 10 goes to the bottom of the list, and most of it should stay there.

Which Processes Should You Automate First?

Run the scoring on ten or fifteen candidates and a pattern almost always emerges. The winners cluster around data movement: information that already exists in one place being manually re-entered somewhere else.

Consider a small manufacturer we can sketch as a composite. Orders arrive by email as PDFs. Someone re-types them into the ERP. Someone else copies ERP data into a production spreadsheet. At month end, a third person reconciles the spreadsheet against the ERP it was copied from. Score it: frequency 5 (daily, dozens of orders), rule clarity 4 (the fields map cleanly, with a few exception cases), pain 5 (three people touch it, everyone hates it), risk 4 (errors get caught downstream at picking, annoying but survivable). Total: 18. That's your first project.

Compare that with "use AI to optimize our production schedule." Frequency is high, sure. But rule clarity is a 2, because scheduling lives in the head of one planner who weighs machine quirks, customer politics, and material lead times nobody has ever written down. Risk is a 2, because a bad schedule idles a work center. Total: maybe 11. Real value exists there, but it's a third-year project, not a first one.

The scoring method also surfaces processes you should automate with something far simpler than AI. If the inputs are already structured, meaning they live in a database, a CSV export, or a consistent spreadsheet, you may not need machine learning at all. A scheduled script or an integration between two systems will do the job for a fraction of the cost, and it will never hallucinate. Save the AI budget for the processes where the input is genuinely messy: free-text emails, scanned forms, photos. Our note on AI document processing covers that category in depth.

What the Score Misses

Four numbers can't capture everything, so before you commit, check three things the spreadsheet won't show you.

First, data access. A process can score 18 and still be a bad first project if the data lives in a system with no export, no API, and a vendor who charges five figures for integration access. Screen-scraping a legacy ERP is possible, and sometimes it's the right call, but it changes the cost and fragility math considerably. This is where an integration-minded engineering partner earns their fee before any AI enters the picture; it's a large part of what our software engineering work actually looks like day to day.

Second, exception rate. Ask the person doing the task what percentage of items are "weird." If they say one in ten, fine: automate the ninety percent and route the weird ten percent to a human queue. If they say half, your rule-clarity score was a lie and the project will drown in edge cases. The honest answer usually comes out in the second hour of conversation, not the first.

Third, an owner. Every automation needs one named person who watches it, handles its exceptions, and notices when it drifts. Not a committee. A person. If nobody wants to own the automated process, that's a signal the organization isn't ready for it yet, and no scoring method fixes that.

When a Spreadsheet Macro Beats an AI Project

Here's an unfashionable truth: for a decent share of the processes that score well, the right tool is a spreadsheet macro, a Power Automate flow, or a fifty-line Python script on a schedule. If the task is "take this structured data and reshape it into that structured format, every day," an LLM adds cost, latency, and a small but nonzero error rate to a job that deterministic code does perfectly.

The rule of thumb we use: if you can describe the transformation without the words "read," "understand," or "figure out," you probably don't need AI. You need plumbing. AI earns its keep when the input is unstructured, when a human currently has to interpret something before acting on it. Even then, the AI's output should be structured and validated before it touches your systems of record, and anything consequential should pass a human review gate until you've measured the error rate. Typically the AI portion of a well-built automation is a thin layer in the middle of a lot of ordinary, reliable software.

That framing keeps budgets sane. It also keeps you from becoming the company that spent six months building an agent to do what VLOOKUP does.

FAQ

How many processes should I score before picking one?

Ten to fifteen is usually enough to see the pattern. Fewer than that and you're probably just ratifying a decision someone already made. Spend a working session with the people who do the tasks, not just their managers, because the managers reliably underestimate exception rates.

Should the first project use AI at all?

Only if the winning process genuinely involves unstructured input like emails, PDFs, or free text. If the data is already structured, a conventional integration or script is cheaper, faster to build, and deterministic. Plenty of excellent first automation projects contain no AI whatsoever.

What's a realistic timeline for a first automation project?

For a well-scoped, high-scoring process, typically four to ten weeks from kickoff to production, including a supervised period where a human reviews every output. If a proposal for a first project runs past a quarter, the scope is too big. Cut it down or pick a different process.

What if two processes tie on the score?

Pick the one with the cleaner data access and the more enthusiastic owner. Tiebreakers are organizational, not technical. A slightly less valuable process with a champion beats a slightly more valuable one that nobody wants to babysit.

If you'd like a second pair of eyes on your scoring spreadsheet, or you've picked a process and want it built by people who ship this kind of thing for a living, that's what our AI and automation practice does. Get in touch and bring your messiest candidate list. We'll tell you honestly which ones are worth automating, and which ones just need a macro.