What triggers it, the two documents that carry it, and the moment the client stops being yours
Closing the deal is not the end of your work on it. The handover is. The moment a deal closes, the Growth Team hands the client to the OS Team, and how well you do that decides whether delivery starts on day one or spends its first fortnight re-asking the client questions you already asked.
What triggers the handover
The trigger is acceptance, not optimism. A deal is closed when one of two things exists:
- The proposal and the MSA, on the ORIGIN template, signed by both parties.
- A purchase order, on the client template, signed by both parties.
Either one triggers the internal approvals that follow. A verbal yes, an email saying we are going ahead, or a signature from only one side is not a closed deal and must not move the Pipedrive stage to MSA.
Source: Register Open items row 87 (item 116, acceptance ruling of 6 September 2026, recorded as CANDIDATE and ruled with two questions still open)
DRAFT STATUS, READ IT AS SUCH
The acceptance rule above sits in Open items as a candidate, not a promoted register row, and the Chief of Staff has two questions still open on it. It is the current instruction. It is not yet a settled standard, so check the register rather than this page if a deal turns on the wording.
There is one gate before delivery can begin, and it is separate from the handover itself: every new client passes the client onboarding gate, which is a pre-MSA start decision (start, start capped, or hold) plus a reconciliation traps checklist. Work before signature happens only under an approved cap.
Source: Register tab 8 row 17
The window
Two timings are written down and both bind you. A decision taken on a call or on WhatsApp is logged within 24 hours. For a physical meeting, the Loom debrief is submitted within 48 hours. The handover is made of those two habits, so if you kept them, the pack is mostly written on the day the deal closes.
Source: Register tab 8 row 10 (decision logging) and tab 14 row 21 (48 hour Loom debrief)
TO CONFIRM
The register sets no window for the handover pack itself, only for the decision log and the Loom debrief inside it. Confirm with the Head of Growth and the Head of OS how many days after signature the pack is due, and record the answer in the register rather than in habit.
The two documents that carry it
Document 1. The ORIGIN Client Brief, client facing
Already prepared and signed during discovery, so by the time the deal closes it exists. It confirms the cause for change and the ambitions, the recommended engagement model, the scope of work checklist, the budget range and timeline, references to every meeting recording, and a What success looks like section carrying the client own success criteria and KPIs in writing. The client signs it to confirm mutual understanding before the proposal is built, which is why the proposal is never the first time the client sees what you understood.
Document 2. The Growth Team to OS Team Handover Debrief, internal only
The extended model of the same brief, with everything you could not put in a client facing document. This one is confidential and is never shared with the client. It carries everything in the Client Brief plus:
- The full deal snapshot: tier, streams, Pipedrive link.
- The client story in depth: culture, reputation, internal dynamics and politics you picked up.
- The stakeholder map, with who decides and how the decision actually gets made.
- Budget detail: the range, the approval status, and where the money comes from.
- Competitive intelligence: who else pitched, and why the client chose ORIGIN.
- Meeting context: tone, energy, and the concerns that were never said out loud.
- Every Loom Notetaker recording link, and the OneDrive folder link for all supporting documents.
- Your recommended engagement model with the rationale behind it.
- Phase detail (AUDIT, FIX, GROW priorities) or stream detail (Strategy, Brand, Technology requirements).
- Any commitment or promise made to the client during the sales process, written down whether or not it was wise.
- Recommended POD composition and notes for the Team Lead.
Both documents file into the client folder on OneDrive, which follows the fixed nine folder template, and are linked from Asana by URL rather than attached.
Source: Register tab 8 row 18 (client folder standard) and tab 14 row 26 (Asana house rule 9)
What delivery has to receive to start without re-asking the client
The test of a handover is not whether you sent something. It is whether the OS Team can open the pack and start. That means the pack contains, at minimum:
- The signed Client Brief, by OneDrive link.
- Every Loom Notetaker recording link from discovery onward.
- The Pipedrive deal link, with the stage current.
- All supporting documents: the RFP, the client deck, brand assets, references.
- The rationale for the recommended engagement model, not just the name of it.
- The internal Handover Debrief in full.
The OS Team reviews the pack and has the authority to reject an incomplete one. That authority is deliberate. A poor handover is one of the four named ways ORIGIN loses value on an engagement, alongside scope creep, underpriced deals and client delays, and the register lists the formal handover package, the Loom debrief and that right of rejection as the controls against it.
Source: Register tab 10 row 14 (value leakage matrix)
THE STANDARD
A clean handover means the OS Team can start without re-asking the client a single question you already answered. If the OS Team has to re-discover what the Growth Team should have documented, the handover failed, whatever the pack looked like. Own the handover the way you owned the deal.
Who owns the client from that moment
The sequence after the pack is accepted is fixed:
- The OS Team validates the handover. Incomplete packs are rejected. No exceptions.
- A Team Lead is assigned, on availability, with expertise and geography factored in.
- The client kickoff is scheduled, attended by the Growth Team, the OS Team and the Team Lead. You introduce, you confirm expectations, then you step back.
- Communication channels are created per POD, internal and external.
- After kickoff, the Team Lead owns the relationship.
That last line is the one people get wrong. After kickoff the client is the Team Lead client. You stay connected, but you are a guest in that relationship, not its owner.
The boundary the register sets
The register states it plainly: the Growth Team does not own renewals, upsells, onboarding or delivery. Those sit with the OS Team. This is not a courtesy. It is a scoping rule, and it is written into the Growth mandates.
Source: Register tab 5 row 17 (Growth mandate boundary) and tab 14 row 12 (Growth Team structure)
Two things follow from it that are easy to misread. First, renewals and upsells still count toward the cycle target even though the Growth Team does not own them, so this boundary is about who runs the work, not about who gets credit for the revenue. Second, once delivery starts, invoicing runs on acceptance through the OS Team: Team Leads report milestone acceptance to the Head of OS, who approves, and the Cashflow Team cannot issue an invoice without that approval. You do not chase an invoice into existence from the Growth Team side.
Source: Register Open items row 87 (item 116, renewals and upsells ruling, CANDIDATE) and tab 10 row 7 (finance flows, Head of OS gate)
TO CONFIRM
Deemed acceptance, where client silence reads as approved after five business days from delivery, sits in the register as a draft marked TO CONFIRM as the house standard, and the acceptance clause itself is recorded as still being built. Do not promise a client an acceptance mechanism in a sales conversation until it is confirmed. Register tab 17 row 7 and tab 7 row 11.
Next: Pricing, approvals and contract basics, Act 05 Section 07, which is gated to client facing roles