Most lost work is not lost in the doing. It is lost between people.

A handoff looks simple: product hands to engineering, sales hands to implementation, implementation hands to customer success, support hands to engineering, finance hands to legal, recruiting hands to the hiring manager. The work moved. Everyone saw the message. The ticket has a new team on it.

Then nothing happens.

The sender believes the work was transferred. The receiver believes context is missing, priority is unclear, or acceptance has not happened. The system records movement, but responsibility floats between both sides.

That is not a handoff. That is a drop.

A real handoff transfers ownership of a work object from one accountable owner to another. It requires a handoff contract: what is being transferred, why now, what context matters, what state the work is in, what is expected next, what risks are known, what done means for the receiver, and how the receiver accepts or rejects the transfer.

This sounds formal until you compare it to the cost of bad handoffs. Customer escalations repeat the same background five times. Implementation learns about sales promises too late. Engineering receives bugs without reproduction steps. Finance receives approval requests without business rationale. Customer success inherits accounts without knowing where value was actually delivered.

Bad handoffs create rework and resentment. Each downstream team starts believing the upstream team is sloppy. The upstream team believes the downstream team is slow. Often both are reacting to a missing ontology.

The workflow should distinguish three moments.

The sender prepares the handoff. They package context, current state, open risks, decisions already made, and remaining work. They do not simply tag the next team.

The receiver accepts the handoff. Acceptance means the receiver has enough context, agrees the work belongs with them, and becomes accountable for the next state change. If the receiver lacks context or authority, they should reject or request clarification without pretending to own it.

The system records the transfer. The owner changes, the state changes if needed, the clock changes if a service level applies, and the previous owner is no longer silently accountable.

Most workflows record only the third moment, and even that poorly.

A good handoff template can be short:

  • Current state.
  • Customer or business context.
  • Decisions already made.
  • Known risks or constraints.
  • What the receiver must do next.
  • Definition of done for this stage.
  • Reopen path if the handoff was incomplete.

The reopen path matters because handoffs are often wrong. A receiving team may discover missing information, wrong routing, or an upstream promise that cannot be met. Without a reopen path, the team improvises through Slack and blame.

Handoffs also need quality feedback. If 40 percent of support-to-engineering handoffs are missing logs, fix the intake standard. If sales-to-implementation handoffs routinely omit success criteria, fix the sales exit criteria. If product-to-go-to-market handoffs miss pricing or packaging implications, fix the launch workflow.

The goal is not to make every handoff heavy. Small work can move lightly. But any repeated or high-risk handoff deserves explicit semantics.

Work disappears when transfer is declared before acceptance. Make acceptance visible.

This is part 8 of 10 in Workflow Ontology.