Fix, Automate, or Build? How to Prioritize Process Improvements

Key Takeaway

To prioritize process improvements, list the specific breaks your documented processes show, score each one on impact and effort, and then make the decision most prioritization grids skip: what kind of fix each item needs. A fix is a decision, an owner, a rule, or a changed step, and it is almost always the cheapest. An automation hands repetitive, rule-based, stable work to a tool you already own. A build is custom software for work that is core to how you win, unique, or scattered across systems and spreadsheets. Then run fixes first in impact order, automations next on processes already fixed, and builds last, on a process that is documented and improved. That is business process improvement applied to a whole list instead of one process.

Why an Impact and Effort Grid Is Not Enough

The standard advice is a two-by-two grid. Put impact on one axis and effort on the other, and you get four boxes: quick wins, big projects, fill-ins, and items to skip. Start with the quick wins, plan the big projects, ignore the rest.

The grid is not wrong. It is incomplete in two ways that matter for a small business.

It tells you how much an item matters, not what kind of work it needs. Two items can land in the same box and need completely different responses. One needs the owner to make a decision on Tuesday. The other needs a developer for six weeks. Scoring them alike hides who does the work, what it costs, and what has to be true before it can start.

It ignores order. On a grid, "automate the weekly report" and "agree on one source for the report's numbers" are two separate dots, and the automation may score higher because it saves more hours. But automate first and you pay to run the disagreement every week. Automation multiplies whatever it touches, which is why AI will not fix your broken processes and neither will any other tool.

Under both sits a third problem: most owners are scoring processes nobody has written down. When we gap-analyzed 16 small businesses across 68 roles and 461 process areas, the average business had just 27% of its work documented. Just over half of role areas, 50.3%, had no documentation at all, and 82% of teams were below 50% coverage. If the process is not documented, the impact score is a feeling and the effort score is a guess.

Step 1: List Candidate Improvements From Your Documented Processes

Lists written from memory in a meeting lean toward whatever broke last week and whoever complained loudest. Start from the documented process instead, then add three signals that show where it hurts.

• The documented process. Walk each one from trigger to finish and note every break: handoffs with no receiver, waiting, double entry, rework, and steps only one person can do. This is the diagnose stage of the four-stage method, and it produces most of the list.
• The pain list. Ask the owner and each team lead for the three things that cost them the most time or trust each week, in their words.
• The interruption log. For one real day, the owner writes down every time someone comes to them and why. The repeats are candidates. The interruption log shows how to run it.
• The misses. Look back over the last quarter for jobs that slipped, late invoices, corrections, credits, and complaints. Each one points at a break upstream.

Write every candidate as a specific break, not a goal. One owner told us on a discovery call that the goal of the whole effort "is to save me time." That is the right goal and an unusable list item. The work is breaking it into the specific places the time goes.

If you are not sure which breaks matter most, start with how to find the bottleneck in your business.

Step 2: Score Each Candidate on Impact and Effort

Score impact through four lenses.

Score each lens from 0 to 3 (none, minor, noticeable, serious) relative to the rest of your list, then add them, so impact runs from 0 to 12. Owner touches get their own lens on purpose: the owner's time is the ceiling on growth in most small businesses, so a break that pulls the owner in costs more than its hours suggest. If you want dollar figures instead of scores, price the manual process honestly first.

Then score effort from 1 to 5.

• 1: A decision and an afternoon. No new software.
• 2: A few days of staff time, or a setting in a tool you already own.
• 3: A few weeks, an integration, or light outside help.
• 4: A project with a vendor, a data migration, or a change across several teams.
• 5: Custom software or a platform change.

The scores compare items on one list; they are not precise. Score as a group, with the people who do the work in the room. If nobody can score an item because nobody knows how that process runs, documenting it comes first. Anything low on impact and high on effort comes off the list for now.

Step 3: Classify Each One: Fix, Automate, or Build

This is the step a generic grid skips, and it changes both the cost and the order. Every candidate gets one of three labels.

Fix: a decision, an owner, a rule, or a step

A fix changes the process itself. It names an owner, writes down a rule, adds a trigger, defines what done looks like, or removes a step nobody can justify. It needs no new software. A yes to any of these makes the item a fix:

• Is the break a missing decision, owner, trigger, or definition of done?
• Would a new person fail in the same spot? Then the spot is the problem, not the person.
• Is a step there only because it always has been?
• Could you change it this week without buying anything?

Our guide on how to streamline a process covers cutting and combining steps safely.

Automate: repetitive, rule-based, stable work a tool you own can do

An automation hands a step to software: a reminder, a status change, a data sync, a scheduled report, a flag when a job sits too long. In a small business the best ones usually live inside tools you already pay for. The item needs a yes to all of these:

• Does it run often, daily or weekly rather than once a quarter?
• Does every run follow the same rule, with any judgment calls written down?
• Has the process held steady for a few weeks since you last changed it?
• Can someone check the output quickly and know whether it is right?
• Can a tool you already own do it?

What to hand to AI first, and what to leave with people, is covered in why AI runs on your SOPs.

Build: core, unique, or scattered across systems

A build is custom software shaped around one of your processes: a quoting tool that knows your pricing rules, a job tracker that replaces the workbook the business runs on, one record in place of the same data retyped into three systems. Two or more yeses make the item a build candidate:

• Is this the work that makes customers choose you?
• Do off-the-shelf tools force you to bend the process to fit them?
• Does the real data live across spreadsheets or systems nobody fully trusts?
• Do several processes share the same data, so one tool would remove work from all of them?

Owners often rule this class out too early. One told us they had never thought they could automate any of it because their process was so unique. Unique is exactly the case off-the-shelf software handles worst and custom software handles best. Custom software examples for small business shows what these tools usually look like, and if the process lives in a workbook, map it before you turn the spreadsheet into an app. When the answer is build, our sister company, The Software Effect, builds custom software you own, not rent. Weigh it first with build vs buy for custom software.

Split items that hold more than one class

An owner told us a routine report took about eight hours, most of it moving numbers from one place to another. That is two items. The fix is agreeing on one source for each number and cutting the steps that copy it twice. The automation is whatever copying survives the fix. Scored as one item it looks like an automation project. Split in two, the cheaper half goes first and shrinks the expensive half.

The three classes side by side

Step 4: Sequence the List

With every item scored and classified, most of the order decides itself.

1. Fixes first, in impact order. They are the cheapest and fastest, and a fix can remove an automation candidate outright, shrink it, or make it safe to run.
2. Automations next, only on processes you have already fixed. Re-score each one after the fixes land, because the hours it would save have usually changed. Go in impact order and break ties with the lower effort score.
3. Builds last, on the documented and improved process. By then the documentation and the fixed process become the build's specification.

Re-run the list every month or two, because each wave of fixes changes what is left. This is the order of business process improvement, document, diagnose, improve, then solve, applied to many candidates at once.

A Worked Example: Six Hypothetical Candidates

The business and every number in this section are made up for illustration. They are not benchmarks and do not come from any client.

The business. A hypothetical 25-person service company whose documented processes, pain list, a day of the owner's interruptions, and last quarter's misses produced six candidates. Each lens is scored 0 to 3, and impact is their sum.

Items 1 to 3 are fixes: written pricing rules so the estimator approves routine quotes, a named receiver in scheduling, and one agreed source for each number. Item 4 must wait for item 3, or it copies two disagreeing numbers faster. Item 5 assumes the scheduling tool already offers reminders as a setting. Item 6 is a build: unique pricing rules, data in four spreadsheets, and every quote depends on it.

What a plain grid would do. Ranking by impact divided by effort gives item 2 a score of 9 (9 divided by 1), item 1 a 7 (7 divided by 1), item 5 a 5 (5 divided by 1), item 4 a 2.5 (5 divided by 2), item 3 a 2 (4 divided by 2), and item 6 a 1.6 (8 divided by 5). That order, 2, 1, 5, 4, 3, 6, puts the report automation ahead of the fix it depends on. The business would automate a report built on two systems that disagree, then rework the automation after fixing the disagreement.

The first three items need no software at all. Item 1 also shapes the build, because it puts the pricing rules on paper, which is exactly the specification a job costing tool needs.

What to Automate First: A Checklist

Before an item moves into the automation wave, it should pass all five. If it fails one, it goes back to the fix list or waits.

• Stable. The process has run the same way for a few weeks since its last change. Automate a moving process and you rebuild the automation every time it moves.
• Frequent. It runs daily or weekly, not once a quarter. Frequency turns minutes into hours worth saving.
• Rule-based. Every fork has a written rule. If a step depends on unwritten judgment, document it first or leave that step with a person.
• Measurable. You know how long it takes today and what correct output looks like, so you can prove the automation helped and spot the day it breaks.
• Already fixed. It has been through the fix wave, with no duplicate checks, habit steps, or ownerless handoffs left inside.

One more question settles the close calls: who fixes it when it breaks? An automation with no named owner is a problem waiting for a bad week.

Where to Start

Pull your documented processes, the pain list, one day of interruptions, and last quarter's misses. Write each break as a specific candidate, score it, label it, and run the fixes this month. For the patterns these lists usually turn up, see business process improvement examples.

Frequently Asked Questions

How do you prioritize process improvements?

List specific breaks from your documented processes, the pain list, an interruption log, and recent misses. Score each on impact (hours, errors, owner touches, customer effect) and effort. Then label each a fix, an automation, or a build, and run fixes first by impact, automations next on fixed processes, and builds last.

What should you automate first?

Work that is stable, frequent, rule-based, measurable, and already fixed. Good first candidates are reminders, status changes, handoff notifications, and data moving between two tools you already own. Leave judgment-heavy steps with people until the judgment is written down, and never automate a step a process fix could remove.

What is a process improvement prioritization matrix?

It is a grid that plots candidate improvements by impact and effort, usually as four boxes: quick wins, big projects, fill-ins, and items to skip. It is a useful start, but it does not say what kind of work each item needs or which items depend on others. Labeling each item fix, automate, or build, and sequencing by that label, closes both gaps.

How do you know when a process needs custom software instead of automation?

Custom software fits when the work is core to how you win, when off-the-shelf tools force you to bend it, or when the real data lives across spreadsheets or systems nobody fully trusts. Automation fits repetitive, rule-based steps inside tools you already own. Either way, document and fix the process first so the tool has a clear job.

Why should process fixes come before automation?

Fixes are usually the cheapest items on the list, and they change the rest of it. A fix can remove an automation candidate outright, shrink it, or make it safe to run. Automating first means paying, every week, to run steps a single decision would have removed.