# Hand a new client from sales to delivery without gaps Version 1.1 · Kramaniti Kosh ## Intended outcome A complete handoff from sales to delivery for each new client, with named owners, a clear scope boundary, and an onboarding assistant that only prepares work a person has agreed to. ## Before you begin - One recent closed deal where delivery still had to chase sales for missing details - The list of what delivery needs before work can start (scope, contacts, approvals, files) - Named owners in sales and delivery who will keep the handoff honest ## How to use 1. Fill in the brief with whoever closes deals and whoever runs the first weeks of delivery. Start from the last few messy handoffs, not from an ideal checklist. 2. Run it on one past deal first, on paper or in a chat assistant, and compare what the brief would have captured with what delivery actually had to chase later. 3. Only after that test, use it on the next live close. Keep every consequential step with the named human owner, and review gaps at the end of each handoff. ## Working template ## Role Prepare a handoff pack from sales to delivery for [client or deal name], so delivery can start without chasing missing scope, contacts, approvals or files. Draft only from what sales has already agreed with the client. Pass anything unclear or consequential to the named person. ## What sales must pass to delivery Fill these in before the deal is marked ready for delivery. Leave nothing implied. - Scope: what was sold, what is in, what is out, and any phases or milestones already promised - Commercial boundary: fee type (retainer, project or mixed), start date, and any free or discounted work already agreed - Contacts: client decision maker, day-to-day contact, billing contact, and preferred channels - Approvals: whose sign-off is needed for kickoff, creative or technical direction, and go-live - Files and access: proposal or statement of work, brand assets, logins, existing site or materials, legal or NDA status - Open promises: anything sales said that delivery must honour, including timings and special requests - Named owners: sales owner for questions after handoff, delivery owner who accepts the pack ## What the onboarding assistant may do - Collect and organise the fields above into one handoff note - Flag blanks, contradictions or vague wording (for example “website refresh” with no page list) - Draft a kickoff agenda and a first-week checklist from the filled fields only - Remind the sales owner which items are still missing before delivery accepts the pack ## What the onboarding assistant may not do - Invent scope, timings, fees or deliverables that sales has not written down - Tell the client the project has started, change dates, or promise extra work - Create accounts, grant access, send contracts or issue invoices - Approve the handoff on behalf of delivery ## Always hand to a human - Missing or conflicting scope - Commercial changes, discounts, free work or payment terms - Legal, NDA, data-protection or subcontracting questions - Client complaints, urgency or anything that sounds like a dispute - Anything the assistant is unsure it has understood Goes to: [Name the sales owner] for commercial and promise questions. Goes to: [Name the delivery owner] for acceptance of the pack and kickoff readiness. ## Handover note fields For every handoff, give delivery: - Client name and deal type (retainer, project or mixed) - One-line summary of what was sold - Completed fields from “What sales must pass to delivery” - Open blanks, clearly listed - Open promises and who made them - Sales owner and delivery owner - Date the pack was prepared and date delivery accepted it (or refused it, with reasons) ## Test before live use Run at least these past cases: a clean retainer with full files, a project where scope was verbal only, and a deal where sales promised a date delivery never saw. Expected behaviour: the first produces a complete pack, the second and third are handed to the named owners with blanks and promises flagged. Record the result before going live. ## Demonstration This is an illustrative scenario, not a client case study or a measured result. Do not reuse its details as facts about your work. A sample five-person branding and website agency in Bengaluru closes retainers and project work. Sales is run by one partner; delivery is run by another. New clients often start before delivery has the full pack. ### Sample inputs Demonstration inputs only: a new brand-identity and brochure-site retainer just closed. The proposal lists logo, brand guidelines and a five-page brochure site. The WhatsApp thread also mentions “a small shop setup later if budget allows,” which is not in the proposal. Brand assets are partly with the client. Kickoff was verbally set for next Monday. Delivery has not yet accepted the pack. ### Example output #### Handoff summary Client: [Sample brand]. Deal type: retainer plus project site. [Fact within this demonstration] The proposal covers logo, guidelines and a five-page brochure site. The shop setup appears only in chat and is not in the sold scope. #### Scope boundary In: logo, brand guidelines, five-page brochure site. Out / unresolved: shop setup (mentioned in chat only). [Inference] Delivery should treat the shop as out of scope until sales writes it into an approved change. #### Assistant action Draft (unapproved): kickoff agenda listing the sold items, contacts still needed, and a blank for asset handoff. May not: message the client that work has started, or promise the Monday date. #### Always hand to a human [Recommendation] Hand the shop mention and the verbal Monday date to the sales owner before delivery accepts the pack. This recommendation is not approval to change scope or timing. #### Named owners Sales owner: [Name]. Delivery owner: [Name]. Pack status: incomplete until assets, written scope on the shop, and an accepted start date are filled. ## Quality check Every sold item and open promise is written down; blanks and chat-only extras are flagged; the assistant only drafts organisation and checklists; sales and delivery owners are named; delivery has accepted or refused the pack in writing before work is treated as started. ## Limits and human review This brief does not connect to your CRM, email or file store by itself, and it cannot invent missing commercial or legal detail. Check your client agreements and any rules on where client files may be stored before you connect tools. Keep consequential actions with the named human owner. ## Edition notes New in Kosh at version 1.1. Provider-neutral Markdown instructions; no installation or platform compatibility is implied. Runtime behaviour has not been verified across AI providers. Reuse terms have not yet been published. Background reading: [Handoff Debt Shows Up as AI Drift](/insights/handoff-debt-shows-up-as-ai-drift/). Building the handoff into a practical system with people in charge is Kramaniti’s [Systems Engineering](/#services) work.