Map the Handoffs: Process Architecture Before Automation
Before you point an AI agent at a process, map how the work moves between people, or watch it fail at the seams you didn't look at.
Part 2 of the Toil Audit series. New to the series? Start with Part 1: Find the Toil: The Required Work Discovery Method.
The Instinct That Breaks Automation Projects
Every company has toil: the work everyone needs done and nobody wants to do. Find the toil that keeps coming up across roles (Part 1 covers how), and the natural next move is to point an AI agent at it.
That instinct is understandable, and it's where a lot of these projects go wrong. Justin Watt, co-founder and CEO of the workflow automation company Switchboard, draws a useful line on an episode of the AI at Work podcast between what he calls "single player" and "multiplayer" AI. Single player AI is one person using a tool to get their own work done faster. Multiplayer AI works across departments, and it inherits every weakness already built into the places where work passes from one team to the next.
Toil that spans more than one person's desk is almost by definition a multiplayer problem. Multiplayer problems need a step most teams skip: understanding how the work moves before deciding how to automate it.
What a Handoff Actually Is
A handoff, in the useful sense, is a defined output from one step that serves as a defined input to the next. Sales confirms a signed contract with the required fields filled in, and onboarding receives exactly that and knows what to do with it. Finance closes a reconciliation in a known structure, and reporting uses it without anyone re-keying numbers by hand.
Most real processes don't work this way, even when an org chart or a process diagram suggests they do. What usually exists instead is a person absorbing the gap. Someone has learned which fields are usually missing from what they receive, who to call when the format is wrong, and how to fix a spreadsheet before it's usable downstream. That person is doing real, valuable work. It's also invisible on any process diagram, because nobody designed it. It built up one workaround at a time until the process depended on it.
This is where automation breaks. An agent doesn't have the knowledge that person built up. It receives the handoff as specified, which is to say incomplete, and it either fails visibly (the good outcome) or produces a plausible-looking result built on missing information (the bad one, because nobody notices until later).
The Three Prerequisites
On the Using AI at Work podcast, Watt names three conditions that decide whether automation across teams works:
- Clean handoffs. Each step produces a defined output that the next step can use as it arrives.
- Usable data. The information the process depends on is structured and accessible, not trapped in a scanned PDF, an inconsistent free-text field, or a spreadsheet with a different layout every month.
- Correct permissions. The automation can access and act on what it needs, and nothing it shouldn't.
Missing any one of these breaks the automation at the handoff, which is also where the value was supposed to be created. An agent that can't get clean data either stalls or fills the gap with something plausible and wrong. An agent without the right permissions either can't finish the job or has broader access than the process needs, which is its own risk. These aren't exotic edge cases. They're what normally happens when automation is pointed at a process nobody mapped.
Why Automating a Broken Handoff Fails Faster, Not Slower
Automating a broken handoff doesn't produce a slightly better process. It usually makes things worse, because it removes the person who was catching and correcting the problem without replacing their judgment with anything. The process used to be broken and slow. Now it's broken and fast, with errors compounding at machine speed and nobody positioned to notice until the output shows up somewhere it clearly shouldn't.
Watt tells the story of a legal team that was drowning in follow-up, constantly chasing the information it needed before an agreement could be signed. Leadership asked for AI to help the legal team. Looking at how the work actually moved told a different story: the problem wasn't legal at all. It was the inputs, from "a 30-person sales team all making their own decisions on what information to gather and when." As Watt put it on AI at Work: "If we can get some better process around the sales process itself, then half of these issues that we would solve with AI are just solved inherently with better process." The client ended up needing about half the AI work it had planned.
Pointing AI at legal would have automated the symptom. Mapping the handoff found the cause one step upstream.
Process Mapping as a Deliverable, Not a Preamble
Treated seriously, process mapping isn't a warm-up before the interesting work starts. It's a deliverable in its own right, because it produces something leadership can act on whether or not an automation project ever launches.
For each handoff the toil depends on, answer four questions:
- Where does the input come from? Name the step, and the person or system that produces it.
- What format is it really in? Not what the documentation says. What actually arrives.
- Who fixes the gaps today? Name the person absorbing the workaround, and what they do.
- What permissions does the work really need? List what the process touches, and nothing more.
The answers sort every handoff into two groups: ready to automate, or needs fixing first. That list is often the first time anyone has made the invisible workaround work visible at all. Combined with a clear picture of where the toil is, it turns a vague sense that "this part of the business is inefficient" into something specific: this toil is real and repeats across the organization, and here is what's missing before it's safe to automate.
The order matters. Map how the work moves, fix what's missing, and only then automate. The next post in this series, Pick Your First Automation, covers how to use that picture to choose the first target: not the biggest pain point, but the one ready to succeed.
Subscribe to get the rest of this series as it publishes: choosing your first automation, and the SRE concept every business leader should know.
This article was drafted with AI assistance and reviewed and edited by Matt before publishing.
About the Author: Matt Shirel writes Praxis CTO, exploring what real technology leadership looks like for growing companies that have outgrown ad hoc decision-making. He brings over 20 years in enterprise IT — spanning infrastructure architecture, cloud strategy, and technology budget ownership — and works hands-on in applied AI, building multi-agent and RAG workflows with tools like n8n and AI coding agents. Process mapping before automation is one of the first things he checks before recommending any AI initiative, because it's the step most often skipped.
