A booking flow can look beautifully complete just before the organisation starts doing the work again. Operations copied parts of the email into a spreadsheet, asked three clarifying questions and finally re-entered the same information into another system. The product celebrated completion at the exact moment the organisation started doing the work again.
Digital products are usually designed around individual tasks. Organisations operate through handoffs. A request moves from customer to sales, sales to finance, finance to operations and eventually to invoicing. If context falls out between those steps, the interface has optimised a local moment while leaving the service to repair itself with email.
Handoffs are product features.
Completion depends on who comes next
A user’s Done is often another person’s Start. The receiving person needs to understand what happened, why decisions were made, what remains uncertain and what they are expected to do.
Designing only the sender’s flow produces thin records: a status changes, but the evidence and conversation remain elsewhere. Designing the handoff means treating context as part of the output.
I ask four questions: what must be transferred, what can be derived, what needs acknowledgement and what can still change? These questions reveal whether the product supports genuine coordination or merely moves a row to another table.
Context should travel with the work
People create context while they work: customer constraints, rejected alternatives, unusual pricing, approval conditions and operational concerns. If the product stores only the final value, the next team inherits a conclusion without the reasoning.
Not every discussion belongs permanently on the record. But consequential decisions should be visible and attributable. Notes, structured reasons, linked documents and history can preserve the information needed downstream.
In the Aerios marketplace, commercial work needed to connect to contracting, operations and finance. The value of a structured request was not just faster quoting. It was the ability to carry consistent information through the charter lifecycle instead of rebuilding it at every departmental border.
Ownership must be explicit
A handoff fails when both parties think the other owns the next step. Status alone rarely resolves this. “Awaiting review” needs an owner, a destination and often a due date.
Show who currently owns the work and who will receive it. Let recipients acknowledge or return it with a reason. If assignment is automated, make the rule visible enough that teams can understand and correct it.
Shared inboxes can help, but they should not become warehouses of anonymous responsibility. Queues need triage rules and clear claims. Otherwise the product recreates the office kitchen problem: everybody notices the empty milk and confidently assumes somebody else has a plan.
Design the return journey
Handoffs are not always accepted. Finance may reject a contract. Operations may identify an impossible route. A customer may change requirements after approval.
Returning work should preserve the original context and explain what needs correction. Avoid resetting the process to the beginning or forcing the sender to compare versions manually. Show what changed, which approvals are now invalid and whether downstream actions have already occurred.
The user-control and error-recovery heuristics are useful here. People need clear routes out of problems. In collaborative products, recovery often involves moving work backwards without turning history into soup.
Notifications are not the handoff
Sending an email does not complete a handoff. It announces one. The product still needs a durable work item, current state and route back to the relevant context.
Notifications should be timely, specific and actionable. Say what changed, why the recipient is involved and when action is needed. Link to the exact record and preserve enough information that the message remains useful without leaking sensitive data.
Allow users to manage notification volume, but distinguish preference from obligation. A critical approval cannot depend entirely on whether somebody muted a channel during annual leave.
Integrations create invisible handoffs
System-to-system transfers are handoffs too. Data moves from CRM to operations, from contract tooling to finance, or from marketplace to cargo management. Users need to know whether the transfer succeeded, what was sent and which system now owns the authoritative value.
Integration failures should appear in the workflow, not solely in an administrator log. Preserve the user’s work, show retry or escalation and avoid creating duplicates after partial success.
This is where product and technical design meet. Idempotency may not be a word users require in the interface, but they certainly notice when pressing Retry creates three invoices.
Measure across boundaries
Teams measure their own stage and miss the delay between stages. A sales flow may take five minutes while the subsequent handoff sits unclaimed for two days.
Measure end-to-end completion, time waiting for ownership, returns for missing information and manual re-entry. Review how often colleagues leave the product to explain a record. Those messages reveal context the handoff failed to carry.
The GOV.UK guidance on measuring services recommends looking at whole journeys and combining performance metrics with research. That matters because a service can have individually efficient steps and collectively exhausting movement between them.
Design for absence
Real organisations contain holidays, shift changes and staff turnover. A handoff model tied to one named person will eventually send urgent work to a beach.
Support delegation, shared ownership and reassignment with audit. Show who covered the work and avoid permanently rewriting history. Returning users should be able to understand what happened while they were away without reading every notification in chronological self-defence.
The seam is part of the product
Handoffs reveal whether a platform understands the service around its screens. They connect decisions, responsibility, evidence and systems. When they fail, people create parallel workflows. When they work, teams can move quickly without sacrificing trust.
Design the receiver’s start as carefully as the sender’s finish. Carry context. Expose ownership. Support rejection, absence and integration failure. Measure the time between stages, not only the time inside them.
The work does not disappear when somebody clicks Submit. It changes hands. The product should be capable of making the introduction.
