Most automation backlogs get built the wrong way. Someone lists every department, asks each one what feels tedious, and ends up with a queue of disconnected requests: invoice entry from finance, ticket routing from support, onboarding steps from HR. None of these get ranked against each other with any real logic, so the loudest team usually wins, not the highest-value one.
There is a better starting point: map the handoffs, not the departments. A handoff is any point where work changes hands, from one person to another, one team to another, or one system to another. Handoffs are where information gets re-entered, where context gets lost, where nobody is quite sure whose job it is to catch a problem. They are also, reliably, where the most expensive delays and errors live. Map them first, and the automation priority list mostly writes itself.
- Automation candidates chosen by department produce a disconnected, hard-to-rank backlog. Candidates chosen by handoff come pre-sorted by where the actual cost is.
- A handoff map lists every point where work changes hands across a process, along with volume, wait time, rework rate, and how rule-based the decision is at that point.
- Queueing theory's Little's Law (work in progress equals throughput multiplied by cycle time) explains why handoffs, not individual tasks, are where delay accumulates.
- Score each handoff on impact and feasibility, not just impact alone. The best first automation is the one you can actually ship and maintain, not the one with the biggest theoretical upside.
What a Handoff Map Actually Is
A handoff map is a simple diagram of a process that marks every point where work moves from one owner to another, and attaches four pieces of data to each of those points: how much volume passes through it, how long work sits there before the next step picks it up, how often it comes back for rework, and how much of the decision at that point follows a fixed rule versus human judgment.
This is different from a standard process flowchart, which usually treats every step as equally interesting. A handoff map deliberately ignores the steps and focuses on the seams between them, because that is where automation tends to pay off fastest. A task that one person does start to finish, with no handoff, is often not a good first candidate. It may be tedious, but it is not usually where delay and error accumulate.
Why Handoffs Are the Right Place to Start Looking
Queueing theory gives a clean explanation for why this works. Little's Law states that the average amount of work in progress equals the average throughput multiplied by the average time each item spends in the system. Applied to a business process, this means that anywhere work sits waiting, whether that is a shared inbox, an approval queue, or a status field nobody checks regularly, that waiting time is doing more to slow the process down than almost any individual task's execution speed.
Handoffs are where waiting concentrates. A task performed entirely by one person moves at that person's pace. A task that crosses a handoff has to wait for the next owner to notice it, prioritize it against their own queue, and pick it up, often with no visibility into how urgent it actually is. This is the same dynamic behind the Theory of Constraints, the operations management framework built around identifying and fixing the single most limiting step in a process rather than optimizing everywhere at once. Handoffs are disproportionately likely to be that limiting step, because they combine queueing delay with a second cost: information loss. Every handoff is a chance for context to get dropped, requiring the next person to re-ask questions the previous step already answered.
How to Build a Handoff Map
Step 1: List Every Handoff, Not Every Task
Walk the process end to end and mark every point where the work's owner changes. Ignore, for now, what happens inside each owner's stretch of the process. You are building a list of seams, not a list of activities. A typical mid-complexity business process, something like customer onboarding or invoice-to-payment, usually turns up somewhere between four and ten handoffs once you look for them specifically.
Step 2: Capture Four Numbers per Handoff
For each handoff, record volume (how many items cross it per week or month), wait time (how long items typically sit before the next owner acts), rework rate (how often an item comes back across the same handoff because something was wrong the first time), and rule-based percentage (your best estimate of what share of the decision at that handoff follows a fixed, describable rule versus requiring human judgment).
You do not need precise measurement instruments for a first pass. Ask the people who own each side of the handoff. Their estimates are usually accurate enough to rank handoffs against each other, even if they are not accurate enough for a finance report.
Step 3: Score Each Handoff on Impact and Feasibility
Rank each handoff on two axes instead of one. Impact captures how much fixing this handoff would matter: high volume, long wait times, and high rework rates all push impact up. Feasibility captures how realistic automation is here: a high rule-based percentage pushes feasibility up, while a handoff dominated by judgment calls, exceptions, or unclear policy pushes it down.
This two-axis approach borrows from the PICK chart, a Lean Six Sigma prioritization tool that plots improvement ideas by payoff versus ease of implementation. Applied to handoffs, it keeps you from chasing the highest-impact seam in the business if that seam is also the least structured, most judgment-heavy one you have. That combination usually means a slow, expensive automation project with a high chance of becoming exactly the kind of week-three abandonment case that gives automation programs a bad reputation.
| Handoff Type | Impact | Feasibility | Recommendation |
|---|---|---|---|
| High volume, high rework, mostly rule-based | High | High | Automate first |
| High volume, high rework, mostly judgment-based | High | Low | Redesign the decision before automating |
| Low volume, low rework, mostly rule-based | Low | High | Automate later, or bundle with a related handoff |
| Low volume, low rework, mostly judgment-based | Low | Low | Leave alone for now |
Step 4: Plot the Map and Look for Clusters
Once every handoff has an impact and feasibility score, lay the process out visually with the highest-impact, highest-feasibility handoffs marked clearly, the way the diagram above marks a single high-risk handoff. Clusters matter here: two or three consecutive handoffs that all score high often indicate that one underlying document, system, or approval chain is the real problem, and a single, slightly larger automation could resolve all of them together instead of building three separate small ones.
Step 5: Pick Your First Three Candidates and Set a Kill Criterion
Choose the top three handoffs by the impact-and-feasibility scoring, not the top ten. Before building anything, write down what "working" looks like for each one: an acceptable exception rate, a target reduction in wait time, or a specific rework-rate drop. Decide in advance how long you will give the automation to hit that target before you either fix it or pull it back to manual handling. Committing to a kill criterion before you start is what keeps a promising handoff automation from turning into a permanent maintenance burden nobody budgeted for.
A Worked Example
Consider a hypothetical mid-sized software company mapping its customer onboarding process, offered here purely as an illustration of the method rather than a real case study. The map turns up six handoffs: sales-to-onboarding, onboarding-to-provisioning, provisioning-to-billing, billing-to-support, support-to-success, and success-to-renewal. The sales-to-onboarding handoff has the highest volume in the map and a rework rate the team describes as "constant," because sales frequently sends incomplete account information that onboarding has to chase down manually. Most of what onboarding needs (company name, seat count, billing contact, plan tier) already exists in the sales system in a structured field. That combination, high volume, high rework, high rule-based percentage, makes it the clear first candidate, well ahead of the success-to-renewal handoff, which has lower volume and depends heavily on a human judgment call about account health.
Common Mistakes When Mapping Handoffs
Mapping departments instead of seams. It is tempting to default back to "what does the finance team want automated," which reintroduces the department-first bias the handoff map is meant to avoid. Stay disciplined about marking the seams, not the teams.
Scoring impact without scoring feasibility. A handoff can look enormously important and still be a poor first project if the decision at that point is mostly judgment. Ranking by impact alone routinely sends teams toward the hardest possible starting point.
Treating estimates as final measurements. The volume, wait time, and rework numbers gathered in Step 2 are a starting point for ranking, not a finished business case. Refine them once you have picked a candidate, rather than spending weeks trying to perfect them before you rank anything.
Automating the whole process instead of the handoff. Once a handoff is chosen, there is a pull toward automating everything upstream and downstream of it as well. Keep the first build scoped to the seam itself. Expansion can come later, once the first automation has proven it can survive real volume.
A Quick-Start Checklist
| Step | Done When |
|---|---|
| List every handoff in the target process | You have a seam-by-seam list, not a task-by-task one |
| Gather volume, wait time, rework rate, rule-based % | Every handoff has all four numbers, even as rough estimates |
| Score impact and feasibility | Every handoff sits in one of the four quadrants above |
| Plot the map and check for clusters | You can point to the two or three highest-priority handoffs on a single diagram |
| Pick top three candidates and set kill criteria | Each candidate has a written target and a decision date attached before build starts |
Frequently Asked Questions
How is this different from a normal process map?
A normal process map treats every step as equally worth documenting. A handoff map deliberately narrows the focus to the points where ownership changes, because that is where queueing delay, information loss, and rework concentrate. You can build a handoff map as a simplified layer on top of an existing process map rather than starting from scratch.
What if a handoff scores high on impact but the team insists it cannot be automated?
Treat that as a feasibility signal, not a reason to skip the exercise. A handoff that seems impossible to automate today is often judgment-heavy because the underlying policy was never written down clearly, not because the decision itself is inherently unstructured. Sometimes the higher-value project is documenting and simplifying the decision rule first, and automating it as a second phase.
The Bottom Line
A department-first automation list ranks requests by who asks loudest. A handoff-first map ranks them by where delay, rework, and lost context actually live, using nothing more exotic than four numbers per seam and a two-axis score. Build the map before you build the automation, pick your top three candidates with a feasibility check attached, and set a kill criterion before you start. That sequence is what turns "what should we automate" from a political question into a measurable one.
