The problem with treating a process as one decision
You've probably already sorted your list into automate, improve, or ignore. It's a useful exercise. But some items won't sit still — they're not one task, they're a chain of steps, and each step behaves differently.
Order fulfillment isn't a single thing. Data entry at the start is predictable. A customer changing their address mid-shipment is not. Treating the whole process as one verb — "automate order fulfillment" — is how businesses end up automating the easy 80% and bolting a brittle workaround onto the hard 20%.
This shows up most for operators who've done the one-week triage on their backlog and still feel stuck on a handful of items. Not because the framework failed — because the item itself is secretly three or four different tasks wearing one label.
What the current state actually looks like
Pull apart almost any recurring business process and you'll find a mix of step types:
- 1Customer submits request
- 2System logs it in a spreadsheet
- !Staff member decides priority by gut feel
- 4Staff member emails a confirmation
- !Edge cases get handled ad hoc, no record kept
- 6Weekly summary report sent to manager
Two steps here are clean candidates for automation — logging and the confirmation email follow a fixed rule every time. One step needs a better process before anything else, because "priority by gut feel" isn't a process, it's a habit. And the edge-case handling needs a home before it can be automated or even improved — right now it's falling through the cracks.
This is normal. Few processes are uniformly ready for the same treatment. The mistake is assuming that because one piece is automatable, the whole thing is — or that because one piece is a mess, nothing can be touched yet.
Three ways to handle a mixed process, and their trade-offs
Automate the whole thing anyway. Tempting when a tool promises end-to-end coverage. The risk: judgment-heavy steps get forced into rigid logic, or routed into a queue nobody monitors. You end up automating the mess, and the mess just moves faster.
Improve the whole thing by hand first. Safer, but slower. You delay the easy wins — the parts that were already clean and ready to hand off to software — while you sort out the harder steps. Teams that take this route often stall, because "fix everything first" has no natural finish line.
Split it. Automate the steps that are repetitive and rules-based now. Improve the steps that are inconsistent or judgment-heavy. Flag the steps that don't need to exist at all. This is slower to describe but faster to execute, because you're not waiting on the hardest 20% to unlock value from the easiest 80%.
| Choice | Choose it when | Watch out for |
|---|---|---|
| Automate | The task is repetitive, rules-based, frequent, and an affordable tool already exists. | Automating a broken process — it just fails faster. |
| Improve | The process is unclear, highly variable, or too low-volume to automate yet. | Stopping at the fix — revisit automation once it runs the same way every time. |
| Ignore | It's low-value, hype-driven, or not urgent — or the task isn't needed at all. | Ignoring forever — note why, and look again next quarter. |
In practice, most processes worth your attention end up as a hybrid. The planning question isn't "automate or improve this process" — it's "which steps go where."
Criteria for splitting a process
Apply these questions to each step, not the process as a whole:
- Does this step follow the same rule every time, or does it depend on context? Fixed rule → automation candidate. Context-dependent → improve first, automate later if volume justifies it.
- What does an error here cost? A typo in a confirmation email is annoying. A misrouted exception in a billing dispute is expensive. High-cost steps need a solid, repeatable process before any tool touches them — automation on top of ambiguity just multiplies the ambiguity.
- How much volume does this step see? A step that happens twice a month doesn't justify automation investment yet, even if it's rule-based. Note it, template it, revisit when volume grows.
- Does this step depend on an earlier step being stable? Automating the summary report before the data entry it pulls from is consistent is backwards — you'll just automate inconsistent numbers faster.
- Does this step need to exist at all? Some steps survive out of habit, not necessity. A weekly summary nobody reads isn't a candidate for automation or improvement — it's a candidate for deletion.
Sequencing: what to split off first
Once you've tagged each step, don't try to act on all of them at once. A rough priority order:
- Automate the stable, high-volume steps now. These pay off immediately and don't depend on anything else being fixed.
- Improve the judgment-heavy or inconsistent steps next. Standardize them with a simple rule, checklist, or script — not a tool. Clean these up before even considering automation for them.
- Flag low-volume or low-impact steps for later. They're not broken, they're just not worth the effort yet. Revisit once the process around them matures or volume grows.
- Drop the steps nobody needs. This is the fastest win available and the easiest to skip, because deleting a step feels less productive than adding a tool.
This is also why hybrid solutions tend to outlast all-or-nothing ones. When you later lock in a win from one of these split-off pieces, the right vehicle — SOP, template, or automation — depends entirely on which bucket that specific step landed in, not on the process as a whole.
Building this into your roadmap
If you're sequencing fixes over a quarter, don't put "automate order fulfillment" on the plan as a single line item. Break it into the steps you've tagged, and schedule them separately — the automation pieces can often ship in week one, while the process-improvement pieces take longer to stabilize and prove out before any tool touches them.
This is the same instinct behind sequencing a 90-day plan: smaller, well-defined pieces move faster than one large, ambiguous initiative. Splitting a process is just that same discipline applied one level down — to the task itself, not just the backlog around it.
The goal isn't to automate more or improve more. It's to stop treating a mixed process like a single decision, so each piece gets the treatment it actually needs — and none of them wait on the slowest one to move.