How to Find the Workflow Worth Automating First

The loudest problem in a building is rarely the most expensive one. The workflow everyone complains about at the Monday meeting gets attention; the one quietly bleeding margin in the background gets lived with. Companies that automate well are not the ones with the biggest budgets — they are the ones with the discipline to pick the right first target.

Picking well matters more than it seems. The first project sets the pattern: it is how the team learns to trust a new system, how leadership decides whether the next one gets funded, and how you find out what building software around your operation actually feels like. A bad first choice — too big, too political, too low-value — can set the whole effort back a year. Here is the method we use to choose.

Start with a candidate list

Before you can rank workflows, you need them on paper. Three ways to surface the real ones, none of which involve a survey:

• Follow one order through the building. From the moment a customer asks for something to the moment the invoice posts, write down every place the work stops, waits, gets re-explained, or gets typed into a second system. Each of those is a candidate.
• Ask people where they wait.Not “what software do you want” — where do you wait, what do you chase, what do you double-check before you trust it. Waiting and chasing are the signatures of a workflow with no system.
• Look for the re-keying. Anywhere data is copied from one place to another by hand — spreadsheet to ERP, email to spreadsheet, paper to anything — a workflow is compensating for a missing connection. Manual data entry is rarely the root problem; it is the visible tip of one.

Most companies produce five to ten candidates this way in a single afternoon. If your list is longer, the patterns in common operational problems can help you group them. Then score them — all of them, quickly, against the same yardstick.

The ten scoring criteria

Each candidate gets a 1–5 score on ten criteria. The first eight measure how much the workflow costs you today; the last two measure how hard it is to fix. Both halves matter — a high-cost workflow you cannot yet build against is a research project, not a first project.

1. Frequency. A workflow that runs twenty times a week compounds its costs twenty times a week. One that runs monthly has to be very expensive per run to compete.
2. Labor burden. Count the whole burden: doing the work, chasing the approvals, checking the result, fixing the mistakes, re-keying the output. The visible task is usually half the real hours.
3. Error cost. What does a typical mistake cost — a credit memo, a reshipment, a quote below margin, a compliance finding? Score by consequence, not by likelihood alone.
4. Delay cost. Some workflows are expensive because they are slow: quotes that age out, crews that idle, shipments that miss the truck. Delay is a cost even when nothing is technically wrong.
5. Number of handoffs. Every transfer between people or departments is a place context dies and work goes invisible. Bottlenecks almost always live at handoffs.
6. Exception rate. A workflow where a third of the runs leave the happy path is really two workflows — and the exception path is usually the unmanaged one. High exception rates mean high value in getting judgment out of inboxes and into a queue.
7. Key-person dependence.If the workflow’s knowledge lives in one head, you are carrying a resignation letter as an operational risk. Systematizing it is insurance as much as efficiency.
8. Customer impact. Does the customer feel this workflow — in quote speed, order accuracy, status answers, delivery promises? Customer-facing friction costs revenue, not just hours.
9. Data availability.Can the system see its inputs? Costs and customer records in the ERP: yes. Judgment in a veteran’s head: not yet. Scores here gate what is buildable now.
10. Implementation complexity. Scored in reverse, as implementation ease: stable rules, few integrations, and a cooperative workflow score high. This is the criterion that keeps a first project small enough to finish.

A simple scoring framework

Keep the anchors crude. The goal is comparison, not precision — you are separating “clearly worth building” from “clearly not yet,” and five-point scales do that fine:

• 1 — negligible. Rare, cheap, fast, or nobody notices when it slips.
• 2 — minor. Real but contained; absorbed by the team without visible damage.
• 3 — moderate. Costs real hours or occasional real money; people have built workarounds.
• 4 — significant. Weekly pain, measurable money, customers or auditors occasionally involved.
• 5 — severe. Daily friction, direct revenue or margin exposure, or a named risk everyone knows about.

Two rules keep the exercise honest. First, score with the people who do the work in the room — a manager’s guess at labor burden is usually half the truth. Second, write a one-line justification for every 4 and 5. The notes are where the real conversation happens, and they are what you will reread in six months.

A worked example: quote approvals at a distributor

Take a mid-size industrial distributor deciding between two first projects: Candidate A, the special-pricing quote approval workflow, and Candidate B, automating the monthly operations report. Candidate A looks like this today — an illustrative workflow, but a recognizable one:

Illustrative workflow — the candidate as it runs today, before any build. Note where work waits and where it gets re-keyed.

Scored in a working session with the inside sales manager and the ops director, the two candidates come out like this:

Candidate A wins on nearly every cost criterion: it runs daily, it touches customers directly, and its errors are priced orders, not wrong charts. Candidate B is no slouch — two working days a month of assembly is real money — but its audience is internal and patient. Notice, though, that B beats A on implementation ease. That is a real tension, and the next section is about how to resolve it.

Three selection mistakes to avoid

The framework is simple; the failure modes are human. Three come up often enough to name:

• Automating the loudest problem. The workflow with the most vocal victims is not always the most expensive one. Score everything on the same sheet before letting volume substitute for evidence — the numbers frequently disagree with the room.
• Letting the tool choose the target.“Our ERP vendor has a module for that” is a reason to evaluate a workflow, not a reason it ranks first. A mediocre fit for a high-value problem beats a perfect fit for a low-value one. Custom vs. off-the-shelf covers that trade-off in full.
• Boiling the ocean on project one. If the first build touches five departments and three systems, it will take a year and teach its lessons too late. Shrink the winner until a single team can feel the improvement within weeks.

How to read the results

The totals rank your candidates, but three readings matter more than the raw order:

1. Check the gates, not just the sum. Data availability and implementation ease are gating criteria. A 42-point workflow with a 1 on data availability is not a first project — it is a second project, after something else creates the data. Score high-cost, low-readiness candidates honestly and park them.
2. Look for a quick win that is not the winner. Sometimes the #2 or #3 candidate is 80% of the value at half the complexity. A first project that ships in weeks teaches the organization more than a perfect one that ships in a year. How long an internal tool takes is driven less by features than by how many systems and departments the workflow touches.
3. Narrow the winner until it is small.“Quote approvals” can shrink to “below-floor quotes for the two biggest product lines.” Scope the first build to the segment with the highest scores, prove it, then expand. The workflow will still be there — and now you will have a working system to extend instead of a blank page.

What you should have at the end of this exercise is one workflow, a written score you can defend to a skeptical CFO, and a rough cost picture — the ROI calculator and the guide to what custom internal software costs turn the labor, error, and delay scores into payback arithmetic. If the workflow you land on happens to live in a spreadsheet, the seven signs piece will help you decide what to do with the file itself.

Or bring the list to us. A Workflow Review is this exact exercise done together: we walk the workflow, score it against your other candidates, and tell you plainly whether it is worth building — and if it is, what the smallest useful version looks like.