A handoff is only worth writing if the person receiving it can act without coming back to ask. That is a higher bar than it sounds, because the failure everybody has lived through is not a handoff with a section missing. It is a handoff that fills one.
Somebody writes "about 120 seats, two-year term" from memory. It reads exactly like a line copied off a signed order form. The person acting on it was not on the call — that is the whole reason they are reading this — so they have no way at all to tell the two apart, and they find out in week three, in front of the customer.
So this use case draws one line and draws it in code. A commercial term — an amount, a term length, a seat count, a discount, a billing method, a contract date — appears in the brief only when a document attached to the deal ticket says so. A figure quoted from a comment, an email, a call note or the ticket's own description is refused, and refused by the parser rather than by asking a model nicely. What appears instead is the term's name, the sentence "Nobody wrote this down", and an entry under Waiting on you with a person against it.
This handoff declares no CRM connection. There is no deal record behind any figure in it, no email thread and no call recording, and every brief prints that list in full, on every run, whether or not anything was missing. A section that only appears when something went wrong is one people learn to read as an error rather than as the standing truth it is. Saying it plainly is not a disclaimer — it is the reason the rest of the brief can be trusted.
What it carries across is the part that usually lives in one person's head: why they bought, what was promised, and — the expensive one — what was explicitly declined, so the next person does not offer it again. Who the people are, and the one thing each cited record shows they care about. What is most likely to stall. And the onboarding steps the record actually supports, each pointing at the line that says the step is needed.
Every open question ends with a name. Not "someone should chase the invoicing question" — a person or the role that owns it, and a brief carrying an item nobody owns is refused before it is written. An unowned to-do is how a handoff quietly becomes nobody's problem.
The onboarding plan is where a handoff usually turns back into a memory. Six steps ship by name, in the order they have to happen, and each one carries the day it is due. One date comes from the brief — the start date, taken from a document attached to the deal ticket — and every date after it is worked out from that, in working days, in code. A date moved by a single day is not printed with a note; the whole brief is refused, because a plan whose spacing quietly drifted is a plan nobody can act on without re-deriving it themselves.
That start date is held to the same rule as a seat count, and for the same reason. "We go live on the first" typed into a thread is somebody's memory of a negotiation, and everything else in the plan moves when it turns out to be wrong. So a date needs a document behind it or the step reads that nobody wrote it down. On a board where nothing is attached, every step reads that way, and the plan is still a plan: it says what has to happen, in order, and admits the one thing it does not know.
It creates no onboarding tickets, and that is a decision. A ticket a model creates carries no key that survives a second run, so a deal dragged in and out of the won column would file every step again and nothing in the product could stop it. One write happens instead, and it is a set rather than a create: the deal ticket's accountable owner becomes the person you named. Setting it twice changes nothing, which is what makes the whole run safe to repeat. The brief itself is a document on the deal ticket, so a second run is a new revision rather than a second document somebody has to choose between.
The kickoff is proposed and never booked, and that is the same decision again. Writing to a calendar needs a human decision in front of it, and the honest version of that decision has to show you the time it is about — which it could not, because the approval would have to be granted before any calendar was read. A duplicate invitation in a customer's calendar is also not something an apology fixes, and this runs every time a card enters a column. So the brief carries up to three times that free/busy proves you are free, and a line saying plainly that nothing has been booked. What it reads is free/busy on the one connected account: times somebody is unavailable, never what those times are for, and never anybody else's calendar. If nothing is connected the brief says no times were checked — which is not the same sentence as saying nothing was free, and the two are kept apart in code rather than left to phrasing.
Nothing on the deal ticket is trusted. The step that reads it holds Aestus reads and no way out. The step that writes holds one tool and cannot look around. The owner you name is checked against your own organisation before anything is written, and an agent is refused outright — an agent is never accountable for a customer.