What a Dependable Handoff Needs

A pilot succeeds because its creator is close to it. The creator knows which inputs break the prompt, which colleague to ask when a case looks odd, and which numbers on the dashboard to trust. None of that is written down, and none of it transfers when a second team is told to follow the same steps. Handing off a workflow is therefore a different task from documenting it. This lesson sets out what a dependable handoff contains and who must own each part.

Following steps is not the same as running a workflow

Consider Marlow Freight Services, an invented logistics firm. Its accounts-payable team piloted an assistant that drafts matches between supplier invoices and purchase orders. The pilot lead, Imran, wrote a clear set of steps. The accounts team at a second depot adopted them within a week and the match rate looked fine. Yet every time an invoice arrived with a missing purchase order, a split delivery or a disputed price, the depot staff messaged Imran. He answered within the hour, and everyone concluded the rollout was going well.

It was not. The steps covered routine cases. The unusual cases, which are the costly ones, depended on a person who had other work and might change roles. The second depot could follow the steps but could not run the workflow, because the decisions around the steps had no home.

The four things a handoff must confirm

A dependable handoff confirms four things, in writing, before the receiving team is on its own.

A support and exception route. Someone must be named to answer questions, and a separate path must exist for cases the workflow was not designed for. Routing exceptions to the authorised owner, and recording how each one was decided, is what stops the same odd case being settled differently on different days. A general statement that help is available does not count as a route.

A named maintainer, and a path for approved changes. Instructions, templates, reference data and settings all drift. One person or small team must be responsible for editing them, and there must be a clear way for an approved change to reach every user so that no one keeps working from an old copy.

Agreed evidence checks and change triggers. The receiving team needs to know which measures show the workflow is still working, how often someone looks at them, and what result or event forces a review. Without this, a slow decline in quality is noticed only when a customer or auditor notices it.

A confirmed accountable business owner, and the decisions that person may make. The owner is a manager in the business, not the tool's builder. The owner decides whether the workflow runs, pauses, widens or stops, accepts residual risk, and approves changes to its purpose. Write the list of decisions down, because an owner who does not know the limits of their authority will either escalate everything or approve things they should not.

Availability is not ownership

The most common handoff failure is quiet. The pilot creator stays reachable, so questions get answered, and the arrangement looks like ownership. It is only availability. The creator cannot approve a change to the workflow's purpose, may not hold budget, and may be reassigned next quarter. When a question lands on whoever happens to be free, the organisation has shifted accountability to the person least able to carry it.

A useful test is to ask what happens if the creator is unreachable for a month. If the honest answer is that unusual cases wait, or that staff improvise, the handoff is not finished. A second test is to ask who would be called if the output was wrong and a customer was affected. The answer should be a named role with authority over the workflow, not the person who built it.

Who decides what

It helps to separate three kinds of decision. Operational decisions, such as how to handle one odd invoice inside agreed limits, belong to the trained user or team lead. Change decisions, such as editing instructions or switching a model, belong to the maintainer working under change control and with the owner's approval where the effect is material. Boundary decisions, such as using the workflow for a new type of customer or accepting a higher error rate, belong to the accountable owner or the sponsor above them. When a decision falls outside a person's remit, the route must say where it goes next.

Handoff also needs a short readiness conversation, not a ceremony. The receiving team walks through three or four real exception cases from the pilot and says who they would call and what they would do. Gaps show up quickly: an owner who has not heard of the project, a maintainer with no edit rights, a support address nobody reads. Leaders should treat a gap found in that conversation as a success of the process, since it was found before a live failure.

What to take away

A handoff is dependable when the receiving team can answer four questions without calling the creator: who do I ask, who changes the instructions, how do we know it still works, and who decides when it should not run. If any answer is a person's name chosen for convenience rather than a role chosen for authority, keep working on the handoff before widening use.