Field note 001Operations8 min read

The handoff
is the process.

Most process maps describe the work. Few describe the moment when the work changes hands. That omission is where delays, rework, and quiet frustration begin.

By the editors

August 3, 2026

Business process design

A hand moving a card across annotated process diagrams on a worktable — A process becomes clear when the team can move the work, not just name the steps.

A process map can look complete and still hide the most important part of the work. The boxes name activities: review the request, price the job, approve the terms, schedule the team. The arrows seem to connect them. Yet an arrow does not tell us who sends what, when the next person knows it is ready, or what happens when the package arrives with a missing fact. The arrow stands in for a conversation that the diagram has not captured.

That missing detail matters because a business rarely fails at a task that one skilled person owns from start to finish. It slows down when the task crosses a boundary. Sales passes a promise to delivery. A buyer sends a request to finance. Support asks product for a decision. Each side may do its own work well, while the whole system remains hard to use.

Start where ownership changes

Teams often begin process work by listing every step. This creates a large inventory and a long meeting. A faster method starts with ownership. Ask where the work changes hands. Then inspect each change with four plain questions: What must move? Who moves it? How does the receiver know it is ready? What proves that the receiver accepted it?

The answers expose gaps that a task list misses. A sales manager may say a signed order starts delivery. The delivery lead may wait for payment terms, a named client contact, and a confirmed start date. Neither person is wrong. They use different definitions of ready. Until the business chooses one shared definition, people will fill the gap with messages, meetings, and memory.

“An arrow is a claim. Test what must cross it.”

This is why a good handoff has a small contract. It does not need legal prose or a new software system. It needs a sender, a receiver, a clear package, and an agreed signal. The package might be a short form, a record with required fields, or a file with a set name. The signal might be a status change rather than an email. The form matters less than the shared rule.

Two people tracing a junction in a wall-mounted process map made from cards and thread — Inspect the junction together. The sender and receiver often hold different ideas of “ready.”

Measure the wait, not just the work

Many reports measure how long people spend doing a task. They miss the time that work spends waiting between tasks. A ten-minute check may sit in a queue for two days. If a team makes the check nine minutes instead of ten, the customer will not notice. If it removes the two-day wait, the customer will.

Record three times for each key transfer: when the sender declared the work ready, when the receiver accepted it, and when the receiver began. The gaps tell different stories. A long delay before acceptance often means the signal is weak or the package is poor. A long delay after acceptance may point to queue size, priority, or capacity. Without those times, every delay looks like a vague staffing problem.

Design the exception at the same time

Standard paths get most of the attention, though exceptions reveal the quality of a process. What should the receiver do when a needed field is blank? Who decides whether an urgent request can skip the queue? Where does declined work go? A process that answers only for perfect inputs is a sketch, not an operating rule.

Give each common exception an owner and a return path. Do not let poor work vanish into a private chat. Return it through the same visible system, with a reason the sender can act on. Over time, the reasons become useful data. If one missing fact causes half the returns, change the intake point. If every “urgent” request skips the queue, repair the priority rule.

Make one transfer better this week

Choose a handoff that happens often and causes mild, steady pain. Avoid the rare crisis. Sit with one sender and one receiver. Watch a real item move between them. Write down the package, signal, acceptance, and exceptions as they exist now. Then agree on one change small enough to try for five working days.

At the end of the week, count returns, questions, and waiting time. Keep the change if the numbers and the people agree that it helped. Revise it if they do not. This rhythm turns process design into ordinary management: observe the work, set a clear rule, test it, and keep what works.

The best process map is not the one with the most complete set of boxes. It is the one that helps people move work without guessing. Draw the tasks, but spend your attention on the arrows. That is where one person’s done becomes another person’s start—and where a business proves that it can act as one system.

Next field note

Stop automating unclear decisions.

Read what Process Marginalia studies