A sales rep changes a deal's stage and sends it to onboarding. The CRM shows progress. But who accepted the customer, checked the information and took responsibility for the next action? A stage change alone answers none of those questions.
Workflow design makes those responsibilities explicit. A useful map shows who does the work, what lets it move to another role, and what happens when the next person can't take it. The system then needs to record those events well enough that someone can find work that's waiting or has been returned.
I start by looking at how people work, including the repeated mistakes and the steps they handle outside the official process. That comes before deciding which software to connect. A missing owner needs an ownership decision. A confusing offer may need a product decision. Automating the transfer won't resolve either one.
This is the practical work behind a process map: follow a lead, order or ticket through the business until someone delivers the promised result. Name the handoffs. Include the cases that come back. Give the person handling each exception enough information and authority to do something about it.
The first question is what the team is trying to deliver, and where its present way of working prevents that.
Start with the people doing the work
A request to automate lead routing can conceal several different problems. Sales and marketing may disagree about qualification. Reps may be receiving records they can't use. The receiving team may already have more work than it can handle. Each situation can produce a queue of untouched leads, but each needs a different change.
I start with the problem independently of whatever I'm selling. Applied to workflow design, that means asking who experiences the delay, what they're trying to accomplish, and what keeps happening when the process breaks. The evidence is in actual records and conversations with the people doing the work.
Define what should happen for the customer
The future needs to be observable. For an onboarding handoff, that might mean a customer receives the promised next action, a named person accepts responsibility, and missing information gets requested without the customer having to chase several teams. That's a proposed outcome to agree with the team, not a claim that every business needs the same onboarding process.
Then identify what has to change. Someone may need authority to reject an incomplete handoff. Sales may need to collect information earlier. A manager may need to change how work gets allocated. Those decisions affect the workflow before any automation runs.
Follow the promise through delivery
The workflow connects qualification, sales and delivery. Qualification decides who should enter the process. The sales process carries the relationship toward an agreement. Fulfillment delivers the result that agreement promised.
Workflow mapping connects those activities. It makes the conditions for entry, the responsibilities between roles, and the delivery work visible. An enforced sales handoff can still deliver the wrong customer to an unsuitable service. That calls for revisiting qualification or the offer.
Once the intended result and the required changes are clear, draw the work the team is doing now. Keep proposed changes distinguishable from observed practice.
Put each action in a lane someone owns
A swim-lane diagram groups actions by the role responsible for them. Sales development, account executives, onboarding and support might each have a lane. The names should match how the team divides responsibility. A small business may have one person covering several roles, and those roles still describe different jobs.
Place each action in its owner's lane. An arrow within a lane connects internal steps. An arrow crossing into another lane marks a handoff. That crossing is where you need to specify what leaves one person's responsibility and enters another's.
Find the work between roles
A step that won't fit into a lane exposes an unresolved decision. Who requests information missing from a lead? Who owns a customer while sales and onboarding disagree about readiness? Putting that work between two boxes doesn't assign it to either team.
Give the action an accountable role, including authority to resolve it or escalate it. A shared queue can help distribute work, but someone still needs responsibility for items that remain unclaimed. Otherwise, the queue records the absence of ownership without correcting it.
Draw the routes people use
Build the map from actual work. Trace a completed record, then a returned or stalled one. Ask the people involved what they received, what they did next and where they had to go outside the documented process. Include requests for clarification, reassignment and repeated checks.
A simplified diagram can help explain the overall flow, but the operating version needs the recurring exceptions. An incomplete lead may return for more information. A receiver may reject a handoff. An unavailable owner may require reassignment. Each route needs somewhere to go and someone responsible for moving it.
Keep the distinction between observation and approval. A workaround tells you where the official process may be failing. It can also bypass a necessary safeguard. Record the workaround, investigate why it exists, and decide whether to change the rule or restore compliance. Copying every bypass into a new diagram would preserve the same risk.
Show the map to the people who run the workflow and have them trace the cases they handle. Their corrections supply missing steps and competing definitions. A corrected diagram gives you places to measure. It still needs evidence that a handoff crossed the boundary successfully.
Measure when the receiver accepts the work
A handoff has a sender, a receiver, a record or artifact being passed, and an acknowledgment. The sender's action starts the transfer. The receiver's acknowledgment confirms acceptance of the next responsibility. Completing that responsibility is a later event.
Those events need distinct meanings. A notification delivered to a channel proves delivery of a message. A record appearing in a queue proves placement in that queue. Neither necessarily proves that the next owner has checked the information and agreed to act.
Keep transfer and completion separate
Choose the evidence your team will use for each event. A CRM action, task acknowledgment or recorded response can work if the people involved understand what it means. Keep the record identifiable across the transfer so that a returned item can be connected to its original submission.
An inspection of a handoff should answer these questions:
| Event | What to record | What it tells the team |
|---|---|---|
| Sent | Sender, intended receiver, item and timestamp | Someone requested a transfer. |
| Accepted | Receiving owner and timestamp | Someone took the next responsibility. |
| Returned | Reason and person responsible for resolving it | The transfer needs correction. |
| Completed | Result and completion timestamp | The accepted action reached its stated end. |
Measure elapsed time between sending and acceptance, and inspect how often items come back for missing information. Keep unaccepted items visible in a backlog. Looking only at completed transfers leaves out work that's still waiting.
Read the slow cases
A typical handoff time can conceal a long wait for some items. Look at the distribution, then inspect the records at the slow end. Were they missing information? Did they arrive while the receiver was unavailable? Did both teams think the other one owned the response?
The answers help distinguish a capacity problem from a routing or information problem. A new alert won't create capacity, and a larger team won't resolve an undefined handoff.
Agree on a response target that fits the work, then give a named role responsibility for breaches. An alert needs an action attached to it: accept, reassign, request information or escalate. Record what happened next so the team can tell whether the response resolved the delay.
Make the conditions for a transition enforceable
A gate prevents work moving into a state it isn't ready for. The team defines the conditions, and the system checks them when someone requests the transition. A policy that asks people to fill in a checklist after advancing the record leaves the next team handling incomplete work.
Qualification provides a useful example. I use explicit criteria to decide whether a prospect should reach a sales conversation. The criteria belong to the offer and the customer. Copying another business's filter without understanding either can exclude suitable prospects or admit unsuitable ones.
Check what the receiving role needs
Suppose a team requires a discovery record before a deal can move to proposal. Define what that record must contain, who supplies it and who can confirm it's ready. A checkbox labeled "qualified" conceals those decisions if different reps use it to mean different things.
The gate should identify what's missing when it refuses the transition. The person correcting the record needs to know where to enter the information and how to submit it again. If the receiving role must acknowledge the handoff, keep that acknowledgment separate from the sender's readiness declaration.
Use enforcement where the condition protects a necessary part of the work. Making every field mandatory can force people to enter guesses just to proceed. Ask whether each requirement changes a decision or enables the receiving person to act. Remove requirements that have no such purpose, and keep safeguards the workflow depends on.
Give refused work an owner
A rejected transition needs a path. A lead with missing information might return to the person responsible for collecting it. An absent receiver might trigger reassignment. A disagreement about qualification might go to a role authorized to decide. Record the reason, next owner and condition for resubmission.
Some situations need a deliberate exception. Define who can authorize it, which conditions they may override, and what reason gets recorded. Any protection that can't be overridden needs to remain enforced. A documented exception helps the team distinguish an authorized decision from a bypass nobody noticed.
Failure paths belong in the same operating map as successful ones. Give recurring failures a response target and an escalation route appropriate to their consequence. The system should retain the failed attempt and the resolution, so a later review can tell whether the gate prevents bad transfers or keeps rejecting work the business intended to accept.
Automate a defined part of the workflow
I worked with a solar agency that needed to aggregate performance across its client accounts. We built the supporting data infrastructure and a dashboard so the agency could see which accounts were doing well and which needed attention.
The agency distributed tasks across its buyers
The agency also used an automated task list for its media buyers. Triggers monitored deviations from average performance or anomalous results and created tasks. The tasks were randomized and distributed across the buyers instead of assigning each buyer permanently to particular accounts. The work included actions such as adjusting an ad set or reviewing an account's ads.
That arrangement gave the team flexibility when a buyer was away. It also separated the event that called for attention from the person allocated to handle it. The system could create and distribute an actionable task while the media buyer still had work to perform.
I want an automation to start from a defined event, create a defined piece of work and assign it to someone.
Check whether the step earns automation
The work should be understood before it becomes an automated rule. A process that routes incomplete records to the wrong team can keep doing that after you've connected the tools. More execution doesn't repair the routing decision.
Frequency, clarity and recovery are useful tests. Ask how often the action occurs and what effort it consumes, including the effort required to build and maintain the automation. Identify the conditions that can be expressed as rules and the cases that still require a person's judgment. Then decide what happens when execution fails.
Recovery needs a visible state and an owner. If a task wasn't created, someone needs a way to find the missed work. If delivery is uncertain, an operator needs to check what happened before sending it again. How to recover depends on the consequence of duplication or omission.
Tools such as Make, n8n and Zapier are part of my automation work. The deliverable also includes alerting, logging and runbooks. Those give the team a way to understand and operate what was built after the initial setup.
A step can remain manual while its inputs and response instructions become clearer. Keep that option available. The person taking over still needs to know what to do when the ordinary path fails.
Leave instructions for the person handling the failure
A workflow can assign a ticket correctly and still leave its owner without a usable response. The experienced operator knows which records to check, which repair is safe and when to involve someone else. A new operator needs that knowledge in a form they can use while the problem is happening.
A runbook records the response to a recognizable situation. General documentation explains how a system works. The runbook helps someone act within it. It needs enough context to establish when it applies, followed by instructions that name the tools, records and decisions involved.
Name the trigger and the actions to take
Begin with the trigger. Describe what the operator can observe and how to distinguish this situation from similar ones. "A handoff is overdue" needs a defined response target and a way to find the relevant record. A vague description makes the operator diagnose the problem again before they can use the instructions.
The response gives the actions in order. Name the role carrying them out and the result to check before continuing. An instruction might read, "Open the outstanding-handoffs view. Find the affected record. Check whether the receiving owner accepted it." The team's actual view name belongs in its runbook.
Escalation explains what to do when the response doesn't resolve the problem. Name the role authorized to make the next decision, how to contact that role, and which evidence to include. The escalation should leave the operator knowing who owns the unresolved work.
Record what happened. The incident or postmortem record should retain the trigger, actions taken and result, with a place to note instructions that were missing or wrong. Give someone responsibility for reviewing those notes and updating the runbook.
Refine the instructions through use
Walk the next applicable case through the runbook and compare the instructions with the work required. A step that needs an experienced person's explanation is a place to add that explanation. A workaround discovered during use may need a process change before it becomes an instruction.
Keep access and authority in the check. Instructions can't make an operator able to view a restricted record or authorize a decision outside their role. Resolve those dependencies or identify the escalation needed.
The useful outcome is another operator handling the situation with the recorded instructions and leaving a result the team can inspect. Repeated use supplies evidence for improving the response.
Follow one handoff through the next real case
Start with a recurring cross-team handoff whose result you can inspect. A lead passed to sales, a sale passed to onboarding or a support escalation will each expose the relationship between a record and the people acting on it. Choose the workflow where a delay or a rejected transfer has a consequence worth addressing.
Keep the first investigation bounded, but collect the inconvenient cases as well as the completed ones. The original map may omit precisely the situations that require the most intervention.
Use the records to choose a change
Use the observations to decide what to change:
- Trace the handoff. Name the sender, receiving role, record being passed and evidence of acceptance. Find items that are still awaiting acknowledgment.
- Record the transfers over a stated observation period. Capture elapsed time and returns, including the reason for each return. Choose a period that lets you observe the work you need to understand, and record the limits of that sample.
- Inspect the distribution and read the slow or unresolved records. Decide whether the problem is missing information, unclear ownership, routing or capacity. Treat the explanation as a hypothesis until the records and operators support it.
- Draw the swim lanes and failure paths. Have the team walk through actual cases and correct the map. Keep current practice and the proposed change separate.
- Make a bounded change to the ownership, handoff conditions or response. State the result it should produce and compare the next applicable cases with that expectation.
- Write the response to a recurring failure as a runbook. Have the person responsible use it, record where they need help, and revise the instructions or the process.
The measurements can change the diagnosis. A gate might reduce returned work while increasing waiting time. A reassignment rule might expose that every available receiver is already at capacity. Read those effects together before adding another automation.
Review rules when the work changes
Keep the workflow current as roles, offers and workload change. Review the map, rules, alerts and runbooks when the team finds a new exception or changes how it delivers the service. An automation that enforces a retired rule needs to be changed or retired too.
Return to the deal sent to onboarding. The next case should show who received it, whether that person accepted it, what happened to missing information and whether the customer got the promised next action.