What does it mean to redesign a process, versus just documenting it?
Every extra approval step in your business probably has a story behind it: the client who complained once, so now every quote needs a second signature; the mistake that slipped through last year, so now there's an extra review before anything ships. Each one made sense on the day it got added. Three years on, nobody remembers why half of them are still there, and a job that should take an afternoon needs four people to sign off on it first.
Mapping a process (covered in how to map a business process) records that pile-up exactly as it stands today. Redesigning it means deliberately changing that structure, not because the current version is wrong exactly, but because it usually evolved reactively, one patch at a time, rather than being designed on purpose.
Redesign asks harder questions than mapping does: Does this step need to exist at all? Does it need to happen in this order? Does it need to involve this many people? A mapped process shows you the current shape. A redesigned process is a deliberate decision about what the shape should be.
Why you should redesign before you automate
This is one of the most common mistakes in automation projects, and it often only shows up after the automation is built: automating a process exactly as it currently runs, unnecessary steps and all.
The problem is straightforward. If a process has a redundant approval, a duplicate data-entry step, or a handoff that exists for no current reason, automating it doesn't remove that inefficiency; it locks it in, and makes it harder to change later because now there's a system built around it, not just a habit. It's the equivalent of paving a dirt path exactly where it happens to run, instead of asking first whether that's actually the best route.
The fix is sequencing, not extra work: simplify the process, then automate what's left. Often, once a process has been properly redesigned, there's meaningfully less to automate than the original version suggested, which usually makes the automation project smaller, cheaper, and easier to maintain, not harder.
How to simplify a workflow before adding any software
Before evaluating any tool, run the process itself through a simplification pass:
- Remove steps that don't change the outcome. For each step, ask what would happen if it were skipped entirely. If nothing meaningful changes, it's a candidate to cut.
- Merge steps that don't need to be separate. Two steps done by the same person, back to back, with no real decision point between them, are often better combined into one.
- Eliminate approvals that aren't adding judgment. An approval step only earns its place if a human is genuinely evaluating something a rule couldn't. If it's a rubber stamp, replace it with a threshold or rule instead of a person's time.
- Question the order, not just the steps. Sometimes the individual steps are all necessary, but the sequence adds delay: work waiting on a step that could happen in parallel instead.
This pass alone, done honestly, often removes more steps than people expect, before any technology decision gets made.
How to reduce handoffs in a redesigned process
Every handoff (a change in who's responsible, or a change in what system the work sits in) is a place where delay, miscommunication, and dropped context accumulate. Reducing them is one of the highest-leverage redesign moves available, with one caveat covered in Common Mistakes below: check what a handoff is protecting before you remove it.
- Give one person ownership of a larger chunk of the process, rather than splitting it into many narrow steps across many people, where that's practical for your team's skills and capacity.
- Consider batching instead of interrupting. If a step happens whenever a request arrives, it fragments everyone's day. Handling requests in batches at set times can protect focus and increase how much gets done overall, at the cost of each case waiting a little longer. Choose based on which matters more for that process.
- Question handoffs that exist only because of system boundaries, not because the work genuinely needs a different person. If the only reason a step moves to someone else is "that's who has access to that software," a connected system removes the handoff without needing to change who's responsible.
How to design exception handling into a redesigned process
Most process documentation, including a lot of SOPs, describes the happy path: the version where everything goes as expected. Real processes have a meaningful share of cases that don't fit that path, and this is consistently where automation projects run into trouble, because "what happens when this doesn't go as planned?" was never actually answered.
When redesigning a process, explicitly design for exceptions rather than discovering them after the fact:
- Identify the realistic exceptions, not hypothetical edge cases: the ones that actually happen with some regularity. A returned order with damage, a client who doesn't respond within the expected window, an invoice under dispute.
- Decide, on purpose, how each is handled (routed to a person, held in a queue, flagged for review) rather than leaving it to whoever encounters it first to improvise.
- Set a clear threshold for when something exits the standard process entirely and becomes a manual, case-by-case matter. Not every exception needs a defined path; some genuinely need a human to look at them individually, and that's a legitimate design decision, not a gap.
A process with a deliberate, if simple, plan for its known exceptions is far more reliable (and far safer to automate) than one that only has a plan for the version where nothing goes wrong.
Where to keep a human decision point in an automated workflow
Redesigning for automation doesn't mean removing every human step. Some points should stay human on purpose, and not always for the same reason:
- Genuine judgment calls: situations where the right answer depends on context a rule can't reliably capture, like whether an unusual client request is worth accommodating.
- High-risk or high-value decisions: anything where an error is expensive enough that a second set of eyes is worth the time it costs.
- Segregation of duties: a second person in the loop not because the step needs judgment, but because no single person should hold end-to-end control over a sensitive transaction. See Common Mistakes below for what happens when this gets merged away by accident.
- Unusual or first-of-their-kind cases: situations that don't match the patterns the process was designed around.
The redesign question isn't "how do we remove every human step?"; it's "which steps genuinely need a human, and for which reason?" Steps that are really just a rule someone happens to be enforcing manually are strong automation candidates. Steps in the categories above should stay human, whatever else in the process changes. The same principle applies when AI is used inside a workflow; see rules or AI: which kind of automation does a task need?