A faster version of a broken step is still broken. It's just quicker about it now. Here's how to find where the real friction sits before you automate anything.
Automating a broken step doesn’t remove the breakage, it just delivers it faster. Before you add AI to any workflow, take it apart step by step and write down who does each part, what they need before they can start, what they hand on, and how long it sits before anyone touches it again. That wait number is usually where the real friction lives, and it’s almost always a handoff between people or teams, not the step itself. This piece walks through a full worked example of one ordinary workflow (client onboarding), shows exactly where a step should be deleted rather than automated, and only then gets to where AI genuinely helps.
Picture the person who runs client onboarding at a small consulting firm. Every new client moves through the same run of steps: contract signed, kickoff call booked, intake form filled in, internal brief written, logins and tool access set up, kickoff call held, welcome email sent. It has been slow for as long as anyone there can remember, and everyone agrees it’s slow. So when a generic AI writing tool came up for renewal last quarter, it got approved without much of a debate. It would draft the welcome email and the internal brief in seconds instead of the twenty minutes those two documents used to eat up.
Three weeks later, the complaints are arriving faster than they used to. Same complaints as before: “nobody told me my login wasn’t ready,” “I filled in that intake form twice,” “the kickoff call happened before anyone had actually read what I wrote.” The email that used to take twenty minutes now takes two. The step got faster. The workflow did not get fixed.
Here’s the part that’s easy to miss when a tool gets picked before the problem gets diagnosed. A workflow that limps along at human speed has, built into it, a handful of accidental buffers. The twenty minutes someone used to spend writing an internal brief by hand was also twenty minutes when a missing detail got noticed, or a step that fired too early got caught before it reached the client. Make that step instant and you don’t remove the mistake sitting inside it. You remove the buffer that used to catch the mistake before it landed.
This is also one of the quieter reasons a lot of AI pilots stall before they ever get to scale: the tool lands on whichever step looked easiest to automate, not the step that was actually causing the delay, and nobody finds out which was which until the complaints start arriving on a shorter fuse than before. We go into that pattern in more depth in our piece on why AI pilots never scale.
Automating a broken step doesn’t remove the breakage. It delivers the same breakage on a faster schedule.
None of this means the answer is to leave the workflow alone. It means the diagnosis has to happen before the tool gets picked, not after the complaints start arriving faster. That starts with actually looking at the workflow, step by step, on paper, before anyone decides what gets automated.
Most people can describe a workflow in one sentence: “we sign the contract, then we onboard them.” That sentence is where all the useful information goes to die. It hides who actually does each piece of work, what they need in hand before they can even start, what they physically hand off next and to whom, and, the part almost everyone skips, how long the work sits untouched before the next person picks it up.
Taking a workflow apart means writing all four of those down, for every single step, before you decide anything about tools or automation. If you’re the only person doing every step yourself, the exercise doesn’t change. You’re just filling in all four columns from your own calendar instead of asking around a team.
Here’s what that looks like filled in for one step of the onboarding workflow above, rather than left as an empty template:
| Field | Answer |
|---|---|
| Who does it | The client, not your team |
| What they need before they can start | The form link, sent only after the contract is signed |
| What they hand on | Completed answers, to the onboarding manager |
| How long they wait | Averages four business days, longer if the client goes quiet |
One step from the onboarding workflow used throughout this piece, mapped using the four questions above.
That last row is the one people leave blank on the first pass, because writing “four days” next to a step that officially “takes ten minutes” feels like admitting the process is broken. It’s the most useful number on the page, and it’s usually the one that tells you where to look first.
Map enough steps this way and a pattern shows up fast. The steps that take the longest to physically do are almost never the steps that take the longest overall. In the onboarding workflow above, writing the internal brief by hand takes about 45 minutes. The intake form the client fills in takes them maybe ten. Between the two, the form accounts for roughly four full days of the timeline, and the brief accounts for none of it, because nobody is waiting on the brief once the intake answers already exist.
A handoff is the moment a piece of work crosses from one person, team, or system to another and sits there until someone on the other side picks it up. It isn’t the step itself that’s slow so much as the gap on either side of it, where the work is sitting in someone’s inbox, someone’s queue, or someone’s calendar, waiting for attention that hasn’t arrived yet.
Wait time per step in the worked onboarding teardown below, before any fix is applied. The internal brief step is excluded here: it carries no wait, just 45 minutes of manual busywork. Illustrative figures built for this worked example, not an audited or industry-wide dataset.
Four of the five slowest points on that chart are handoffs: the client has to sign something, the client has to fill something in, two calendars have to line up, an IT queue has to clear. Only the writing itself, the part the original AI tool in this story actually targeted, sits inside the shortest bar. That’s not a coincidence. Writing is the part anyone can point to and say “that takes a while.” Waiting on someone else is invisible until you write the number down next to it.
If a workflow is slow, check the handoffs before you blame the steps.
Here’s the full map for the onboarding workflow used throughout this piece: all seven steps, all four columns, filled in rather than left blank. This is a worked example built to show the method, not an audited case file from a real client, and the numbers are illustrative rather than a verified industry average. Treat it as a template to copy, not a benchmark to hit.
| Step | Who does it | What they need first | What they hand on | How long they wait |
|---|---|---|---|---|
| 1. Contract countersigned | Client | An agreed proposal | Signed contract, to the onboarding manager | ~2 days |
| 2. Kickoff call scheduled | Onboarding manager | The signed contract | A calendar invite, to the client and delivery team | ~2.5 days |
| 3. Intake form completed | Client | The form link | Completed answers, to the onboarding manager | ~4 days |
| 4. Internal brief written | Onboarding manager | The completed intake answers | A brief, to the delivery team | Same day, plus 45 minutes retyping by hand |
| 5. Tool access provisioned | IT/ops | The signed contract only | Logins, to the client | ~1.5 days |
| 6. Kickoff call held | Delivery lead | The brief and working logins | A verbal handoff, to the delivery team | None, a scheduled event |
| 7. Welcome email sent | Onboarding manager | Notes from the kickoff call | Nothing further, the workflow ends | ~1 day, sometimes more |
A worked example built to show the diagnostic method, not an audited case file. Roughly 11 business days end to end, under 3 hours of that spent actually doing the work.
Add up the waiting and you get roughly eleven business days from a signed contract to a welcome email. Add up the actual hands-on-keyboard work across all seven steps and you get under three hours. Nine and a half of those eleven days is the workflow sitting still.
Step four is the one worth stopping on. Someone reads the client’s own answers on a screen and retypes them into a different document, word for word in most cases. Nothing about that step needs a human doing it, and nothing about it needs an AI tool doing it either. It needs to not exist. The fix is piping the intake form’s answers straight into the brief template, the same fields landing in the same places automatically, which removes 45 minutes of pure busywork without automating a single decision.
Once the map exists, most steps sort themselves into one of three piles fairly quickly. The test is three questions, asked in order, for every step on the page:
| Ask this | If the answer is yes |
|---|---|
| Would anyone notice if this step just stopped happening? | If no, delete it. Nothing downstream needs it to exist. |
| Is it slow mostly because of what happens right before or after it, not the step itself? | Fix the handoff first. Automating a step next to a slow handoff just moves the same wait somewhere else. |
| Is the step itself necessary, correctly timed, and genuinely just slow to do by hand? | This is the one worth automating. |
Run every step in your own teardown through these three questions, in order, before any tool gets chosen.
Run the onboarding teardown through that test and the answers aren’t close calls. The internal brief step, retyping the client’s own words, fails question one: delete it. The intake form and the calendar scheduling both fail question two: they’re slow because of a handoff, not because of the step, so the fix is tightening the handoff first. Attach a hard deadline to the intake form tied to the kickoff date instead of an open-ended request, and stop treating “find a slot across three calendars” as a scheduling problem when it’s really a policy problem: pick a standing weekly kickoff slot and stop renegotiating it fresh for every client. Neither fix touches AI at all.
Before you automate a step, ask whether it needs to exist at all.
If you manage this kind of workflow without owning the budget for new tools, this is also the conversation worth having before anyone requests a purchase: most of what’s slow here gets fixed with a policy change and a form redesign, not a subscription. If you’re a solo consultant running every one of these steps yourself, the exercise is identical. You’re just also the person who has to make the policy change stick.
Go back to the onboarding manager from the start of this piece. Once the retyping step is gone and the intake form has a real deadline attached to it, the AI writing tool she already pays for stops being the thing that broke the workflow and starts being genuinely useful. The brief now drafts itself from structured intake answers instead of from someone’s rushed retyping, so there’s nothing left to introduce by hand. The welcome email drafts from the actual kickoff call notes instead of a template nobody updates. Same tool, used at a different moment in the process. That’s the entire difference between the workflow at the start of this piece and the one at the end of it.
A few more places AI genuinely earns its spot once the process underneath it is sound:
None of that removes a person from the loop. It changes what the person is doing: less retyping, more deciding.
| What AI does | What you still own | How it’s checked |
|---|---|---|
| Drafts the internal brief and welcome email from the client’s own structured intake answers | Deciding whether the brief actually reflects what the client needs, not just what they typed | Onboarding manager reads every brief before it reaches the delivery team, every time |
| Drafts a follow-up nudge to a client who has gone quiet on the intake form | Deciding when to send it and how firm the tone should be | Sent from a named person’s account, never fired automatically |
| Turns a kickoff call recording into a first-pass list of action items | Confirming the actions match what was actually agreed, especially anything about scope or price | Delivery lead checks the list against their own notes before assigning any of it |
The split this article recommends wherever AI takes on a piece of the onboarding workflow above.
Getting a step to this point (correctly sequenced, correctly owned, and genuinely just slow to do by hand) is exactly the workflow-design question our guide to building your first AI workflow picks up where this one leaves off. That guide has its own three-question test for whether a task is a good candidate for automation in general (is it repetitive, is it rule-based, is it worth the setup time). This piece’s delete-fix-automate test sits one step earlier: it’s for deciding what an existing step in a mapped workflow needs before you’re even ready to ask that question. The tool itself is rarely the hard part. Deciding which piece of work it’s actually wired into, and whether anyone keeps using it that way past the first week, is what we mean by the Tool x Workflows x Behavior side of things, covered properly in what makes someone an AI-powered professional.
Pick one workflow you already run. Write down the four columns for every step, on paper if that’s what it takes. Find the step that fails the “would anyone notice” question and delete it before you do anything else. Only then decide what, if anything, gets an AI tool.
Because speed doesn’t remove the cause of the slowdown, it just compresses the part of the process that was never the real problem. In the worked teardown in this article, the writing step people blamed took 45 minutes; the waiting they didn’t measure took over four days. Making the 45 minutes instant also removes the human buffer that used to catch mistakes before they reached the client, so problems can arrive faster instead of less often.
Walk through it step by step and write down four things for each one: who does it, what they need before they can start, what they hand on next, and how long it sits before anyone touches it again. Do this even if you’re the only person doing every step yourself. The wait column is the one people almost always skip writing down, and it’s usually the one that matters most.
A handoff is the moment work crosses from one person, team, or system to another and sits until someone on the other side picks it up. It matters because a step can look slow on paper while the actual doing takes minutes: the intake form in this article’s worked example takes a client about ten minutes to fill in, and roughly four days to actually land back on the onboarding manager’s desk.
For anything genuinely broken, yes. Not every step needs surgery first, though: if a step is well-sequenced, correctly owned, and just slow to physically do, automating it on its own is the right move. The distinction is whether the slowness comes from the step itself or from what happens on either side of it.
It’s usually not the step people complain about, it’s the one with the longest wait column once you’ve written it down for every step. In the worked teardown here, the step everyone blamed (writing the internal brief) accounted for 45 minutes of work. The step nobody complained about (the intake form sitting in the client’s inbox) accounted for four of the eleven days.
This piece uses no external statistics or third-party research; it’s a method-driven diagnostic guide rather than a report on someone else’s findings. The three numbers that appear throughout (11 business days, under 3 hours of hands-on work, and the 45 minutes spent retyping intake answers) come from a worked example built for this article to demonstrate the diagnostic method, not from an audited case file or a survey, and they’re presented as an illustrative walkthrough rather than a verified company’s real figures. The four-question diagnosis method, the worked teardown, the delete/fix/automate test, and the AI-ownership table are Future Factors’ own approach, built for this piece.
Weekly tips. Real examples. Practical help for busy professionals.
We care about your data, check out our privacy policy.