Handoffs: Where You Stay in the Loop

The lead-to-invoice line put checkpoints at four specific seams and left the rest alone. That placement was not taste. There is a small set of rules for deciding where a human belongs in a workflow, and they are the difference between a system you trust and a system you re-read end to end every time, which saves nothing.

The placement rule

Put a checkpoint wherever a step's output, if wrong, would be expensive to unwind. Skip the checkpoint wherever a wrong output just gets fixed in the next step anyway.

Expensive-to-unwind has three usual faces:

• Money commits. Quotes, invoices, discounts, refunds. A sent price is a kept price.
• Reputation moments. First replies, apologies, anything a customer might screenshot.
• Point of no return. Anything sent, posted, or scheduled. Drafts are free; sends are not.

Everything else, an internal summary, a list of candidate ideas, a schedule draft that three more steps will reshape, runs unreviewed. Reviewing those is not diligence; it is the scatter tax sneaking back in with a clipboard.

The two-minute review

A checkpoint is a bounded, specific look, not a proofread. Give each one a short check written into the runbook, so the reviewer knows what they are looking for:

Three named checks beat "look it over." They make the review fast, they make it teachable (Chapter 6 hands this exact list to your office manager), and they make it honest: a checkpoint whose check cannot be written down is guarding against a risk you have not defined, which usually means it is guarding against nothing.

Escalation: the workflow's pressure valve

Some runs will not fit the rails. The customer is angry. The notes describe a job you have not priced before. The follow-up is to someone who also owes you money. Workflows handle this with one standing rule written into every skill on the line:

The escalation rule is what lets you trust the quiet majority of runs. Without it, every output carries the doubt "would it have told me if this one was weird?" With it, weird runs announce themselves, and you spend your judgment where judgment is needed, which was the entire point of the audit's fourth question.

An owner running our HVAC line sees perhaps one ESCALATE a week. That flag is the system working, not failing: it means the other thirty runs came through clean seams and earned their two-minute reviews.

Batching: when the checkpoint moves

Event-triggered workflows produce checkpoints at random hours, and context-switching is its own tax. Where the response can wait a few hours, batch the checkpoints: review the morning's First Responder drafts at 11:30 and the afternoon's at 4. Where it cannot wait, an inquiry reply is worth reviewing within the hour, keep it immediate but keep it to its written check. The runbook states which policy each checkpoint uses, so "when do I deal with this" is never a fresh decision.

Try it now

Go back to the runbook you drafted in the first lesson of this chapter and harden it. For every checkpoint, write the two-or-three-line named check. For every skill step, add the ESCALATE rule to the skill file. Then look for a checkpoint guarding something cheap to unwind and delete it. Most first drafts have one review too many, placed where nerves suggested rather than where cost lives, and deleting it is the moment the workflow starts paying you instead of the other way around.