sales-to-cs-handoff

{
  "skill_name": "sales-to-cs-handoff",
  "evals": [
    {
      "id": 1,
      "prompt": "I run RevOps at Cartelane, a B2B analytics SaaS. We close about 25 mid-market deals a month (sales-led, named CSMs) plus roughly 300 self-serve conversions a month on the same product. We have three CSMs total and they are drowning - my VP of CS told me flat out she can spare maybe fifteen minutes of CSM time per new customer and not a minute more. Right now nothing formal happens when a deal closes. Can you write us a handoff document template that the AE fills out for every deal so the CSM has everything they need?",
      "expected_output": "A handoff design that starts by interviewing, ranks the per-deal packet document last on efficiency, builds wiring plus the live kickoff first, deletes meetings and the document for the self-serve segment, and emits one spec with per-segment rows.",
      "files": [],
      "expectations": [
        "Asks clarifying questions about the motions, the post-sale team, deal volume, current closed-won-to-kickoff timing, what the CRM captures today, and whether AEs are held accountable past close, before producing a design",
        "Ranks the per-deal packet document as the lowest-efficiency rung, below wiring, the live customer kickoff, the internal sync, and the acceptance step",
        "Recommends wiring - a must-block field gate on structured CRM fields plus an assignment rule with a fallback owner - as the first thing to build",
        "Recommends the live customer kickoff as the second rung, and pairs it with wiring as the default build for the mid-market segment",
        "States that the per-deal packet document is promoted only when implementation genuinely spans teams, or when services/an SOW ship with the deal, or under regulated data requirements",
        "Declines to make a per-deal document the artifact of record for mid-market given the stated fifteen-minutes-per-customer ceiling",
        "Deletes both meetings and the packet document for the self-serve segment outright rather than producing a lighter version of them",
        "Names structured CRM fields as the artifact for the mid-market motion and a system event payload for the self-serve motion",
        "Produces one handoff spec with per-segment rows for trigger, artifact, clocks, meetings and acceptance, not two separate specs",
        "Expresses each rung's cost as an order of magnitude - near-zero per handoff after a one-off configuration pass for wiring, about an hour of receiver time for the kickoff - and never as a currency amount",
        "Emits the deliverable in the handoff spec shape with Scope, Trigger, Packet, Artifact, Clocks, Meetings, Acceptance, Escalation, Automation, KPIs and Governance lines"
      ]
    },
    {
      "id": 2,
      "prompt": "Riverbend Metrics here. We're pure product-led - no sales team at all for our self-serve base, about 900 trial-to-paid conversions a month at an average of $49/month. We have exactly two people in customer success and they mostly answer tickets. Our board keeps saying we need a real sales-to-CS handoff process like grown-up SaaS companies have. Should we assign each new paying account to one of the two CS folks for a welcome call, and what else does the handoff need?",
      "expected_output": "A refusal to invent a human handoff for a no-touch motion, replaced by a system-to-system event design: completeness gate on the account record, a signal-to-motion map, an activation event standing in for the kickoff, and the two CS people on exceptions only.",
      "files": [],
      "expectations": [
        "Declines to assign a named human receiver or a welcome call to every self-serve conversion",
        "States that over-serving no-touch customers with human touch is itself a bad experience, not a bonus",
        "Defines the handoff as a system-to-system event fired by a billing or CRM state change such as trial conversion, plan upgrade, or a seat threshold being crossed",
        "Makes the gate record completeness - plan, billing state, signup source or attribution, marketing consent - rather than human-context fields like stakeholder sentiment or discovery notes",
        "Names the activation event as the stand-in for the kickoff meeting",
        "Names time-to-activation as the stand-in for time-to-kickoff",
        "Sets the first automated touch within about an hour of the trigger event rather than within days",
        "Maps signals to motions: conversion to a lifecycle onboarding sequence, a usage threshold to an expansion motion, and silence past a defined window to a re-engagement motion",
        "Assigns the two CS people to exception handling - failed activation after N days, a high-value account inactive, billing failure - instead of to every converting account",
        "Names an explicit owner for the motion map itself, typically growth or lifecycle marketing rather than CS, instead of leaving ownership implicit",
        "Replaces per-deal acceptance with automated validation of record completeness"
      ]
    },
    {
      "id": 3,
      "prompt": "Tessaro Cloud, 40 mid-market deals a month. I need to define the fields an AE must fill before a deal can be passed to CS. Two constraints from my VP of Sales: AEs will give ten minutes per closed deal and not one more, and they already complain loudly about CRM admin. Our conversation-intelligence tool already records and transcribes every sales call automatically. Our head of marketing wants the buyer's webinar attendance and content-download history included in the handover so CS knows what they've consumed. Give me the field list, the order the AE should fill it in, and tell me what to make mandatory.",
      "expected_output": "A field list ordered by retention bought per minute of rep time - recordings first, marketing engagement history last - with only the top four categories must-blocked, every field carrying a named supplier and consumer, and unread fields cut.",
      "files": [],
      "expectations": [
        "States the fill ordering explicitly as ranked by retention bought per minute of rep time, rather than leaving the order implied by the list sequence",
        "Places auto-captured call recordings first in the fill order, because tooling fills them at near-zero rep cost and they carry nuance no structured field does",
        "Places marketing or content engagement history last in the fill order",
        "Recommends leaving the marketing engagement history optional or cutting it, rather than adding it as mandatory as the head of marketing requested",
        "Ranks the goal and success definition, and the commitments made during the sale, above commercial and contract terms",
        "Must-blocks the top four categories only - recordings, goal and success definition, commitments made during the sale, and commercial terms - and leaves the rest optional",
        "Refuses to must-block every field, on the grounds that blocking everything guarantees the gate gets gamed",
        "Gives every field both a named supplier role and a named consumer role",
        "Cuts any field nobody reads at kickoff, stating that an unread field is gate friction with no return",
        "Promotes technical and integration requirements to must-block only in segments where integrations or an SOW routinely exist",
        "Keeps discount rationale, competitive evaluation, org chart and per-stakeholder sentiment as optional rather than must-block, while must-blocking the economic buyer and the day-to-day contact"
      ]
    },
    {
      "id": 4,
      "prompt": "Pellworth Systems. Our CRO wants handoff ceremony tiered by contract value: deals over $80k get the full treatment (written packet, internal briefing, exec-attended kickoff), $20k-$80k get a kickoff call only, under $20k get an automated email. We also have about 600 self-serve accounts a month on a credit-card plan. One wrinkle: our biggest account at $400k is a three-year customer whose ops team has run our product daily since 2023 and is now buying a second product line - under the CRO's rule they'd get the full ceremony. Does this tiering make sense? Write up the segmentation.",
      "expected_output": "A rejection of price as the segmentation driver, replaced by touch level set by the experience each segment needs, with the mature $400k renewal explicitly de-escalated and the self-serve base left alone.",
      "files": [],
      "expectations": [
        "Rejects contract value as the driver of touch level",
        "Sets coverage by the experience a segment needs to feel successful, with price treated as a constraint rather than the driver",
        "Notes that a large, mature customer may need much less than its price tier implies, and applies that specifically to the $400k three-year account buying a second product line",
        "Notes that smaller and self-serve customers expect self-service and one-to-many, so adding human ceremony there is a downgrade rather than an upgrade",
        "Names operational capability - deal volume and available customer-success hours - as the legitimate constraint alongside needed experience",
        "Keeps the same five mechanics unchanged across every segment: a gated trigger, a defined data set, an artifact of record, two clocks, and an accountable receiver",
        "Varies only trigger source, artifact, clocks, meetings, acceptance and receiver by segment",
        "Produces one spec with per-segment rows rather than a separate spec per tier, so segments share gate logic, reason codes and KPI definitions",
        "Deletes rungs a segment cannot afford rather than placing them on that segment's backlog or marking them lower priority",
        "Warns that a rung parked on a backlog gets re-acquired the first time a deal goes badly, even though the volume that made it unaffordable has not changed",
        "Asks what each segment actually needs before assigning ceremony, instead of accepting the proposed price bands as the starting frame"
      ]
    },
    {
      "id": 5,
      "prompt": "Alder & Vance, B2B SaaS, mid-market only, about 30 deals a month. We launched our handoff process eight months ago and the dashboards look great: gate completeness 99.2%, first-submission acceptance 98.8%, zero rejects logged in the last four months. But median time from acceptance to kickoff is 21 business days and p90 is 41, against a 5-business-day target we set. Three customers complained last quarter about being asked the same discovery questions twice, and two of my CSMs still say they start from zero. Leadership thinks the process is working. Is it? What do we do?",
      "expected_output": "A diagnosis that the green numbers are the symptom - the gate checks the wrong fields, the acceptance step is theater, and the 21/41-day kickoff gap is a capacity problem - with quality sampling and field pruning rather than more required fields.",
      "files": [],
      "expectations": [
        "Answers that the process is not working, and treats the green completeness and acceptance numbers as a symptom rather than as evidence of success",
        "Reads near-100% gate completeness alongside quality complaints as the gate checking the wrong fields",
        "Reads high acceptance alongside late kickoffs as a scheduling or capacity problem, not a data problem",
        "Identifies the acceptance step as theater given 98.8% acceptance and zero rejects in four months",
        "Flags fields filled with throwaway non-answers as a likely cause, because completeness measured as non-empty cannot detect them",
        "Recommends a monthly packet-quality spot audit of a sample of deals rather than adding more required fields",
        "Recommends re-checking the must-block field list against what kickoffs actually used, and cutting the fields nobody reads",
        "States that rejecting must carry no penalty for the rejecter, or the gate stays theater",
        "Names the 21-business-day median and 41-business-day p90 against the 5-business-day mid-market SLA as the real failure, rather than the completeness number",
        "Recommends reviewing the reject-code distribution monthly, and reads the empty distribution as itself a finding",
        "Does not propose adding required packet fields as the fix"
      ]
    },
    {
      "id": 6,
      "prompt": "Hollenbeck Group. I'm head of RevOps. We do about 120 SMB deals a month plus 15 mid-market. Our customer success team is four people and reports into the CRO, same as sales. In three years nobody in CS has ever pushed back on a rep about anything - when a deal lands badly they just absorb it. I want to build a hard acceptance gate where CS can bounce a bad handoff back to the AE. Design it for me.",
      "expected_output": "A design that withholds the per-deal acceptance step until a manager sponsors it, deletes it entirely for the 120-deal SMB segment in favour of a sampling audit, keeps it for mid-market, and builds wiring first everywhere.",
      "files": [],
      "expectations": [
        "Declines to start with a per-deal acceptance step for a CS team that has never rejected a rep's work, whatever the efficiency ranking says",
        "Names the missing political standing - CS reporting into the CRO with no history of pushing back - as the blocker, and requires a named manager sponsor before the step goes live",
        "Deletes per-deal acceptance for the 120-deal-per-month SMB segment on volume grounds",
        "Replaces SMB per-deal acceptance with a sampling audit of packet quality plus automated completeness checks, with the gate still blocking",
        "Keeps the explicit accept-or-reject step for the 15 mid-market deals per month",
        "Builds wiring first in both segments: a must-block field gate plus an assignment rule with a fallback owner",
        "Specifies that a reject carries a reason code and a re-submission clock and bounces back to the rep, never sitting in limbo while the customer waits",
        "Escalates a second reject on the same deal to both managers",
        "Routes a bad-fit customer to the sales/CS alignment forum rather than back to the rep, and treats bad fit as an upstream qualification problem rather than a CS problem",
        "States that rejecting must carry no penalty for the rejecter",
        "Notes that reject reason codes only begin rewriting the packet definition after a quarter or so of accumulation, so the step pays off as a compounding asset rather than an immediate win"
      ]
    },
    {
      "id": 7,
      "prompt": "Verrier Industrial. We sell into regulated pharma manufacturing. Nine deals a year, average $600k, every single one ships with a professional-services SOW, and all of them carry data-residency and validated-systems requirements. Losing one account would be about 11% of our renewal base. Our three CSMs are not overloaded - they have time. Our current handoff is heavy and slow and our CRO wants it stripped down to the essentials. What's the minimum we can get away with?",
      "expected_output": "A refusal to strip down: the full high-touch ceremony is promoted whole with the efficiency ratio explicitly ignored, because the three promotion conditions are all met, with technical, compliance and SOW fields must-blocked.",
      "files": [],
      "expectations": [
        "Refuses to strip the process to the default rung and promotes the full high-touch ceremony whole",
        "Names the promotion conditions that are met: losing one account would visibly dent the segment's renewal base, services or an SOW ship with the deal, and regulated data requirements are in play",
        "States explicitly that the efficiency ratio is ignored for this promotion rather than applied",
        "Keeps the per-deal packet document despite it ranking lowest on efficiency",
        "Keeps the internal sync, with the rep briefing the CSM and the implementation or services team together",
        "Requires commitments and the SOW reviewed line by line before any customer contact",
        "Must-blocks technical and delivery requirements, and security, compliance and data-residency requirements, in this segment rather than leaving them optional",
        "Must-blocks SOW ownership and the services delivery timeline",
        "Keeps the explicit per-deal acceptance step at this deal volume rather than substituting a sampling audit",
        "Sets internal handoff within about 1 business day of closed-won and the kickoff held within about 10 business days for this high-touch segment",
        "Explains that the heavy ceremony's value concentrates in the few deals that would otherwise fail loudly, so judging it on the average deal understates it"
      ]
    },
    {
      "id": 8,
      "prompt": "Quillmark, B2B SaaS, ~20 deals a month. Four things I need from you in one go: (1) the sales-to-CS handoff process, (2) the 30/60/90 onboarding plan the CSM runs after kickoff, (3) an account health score so we can see which new customers are at risk, and (4) fix our closed-won stage - reps mark deals Closed Won when they get a verbal yes, sometimes two weeks before the contract is actually countersigned, which is making everything downstream weird.",
      "expected_output": "The handoff spec delivered, with the onboarding plan, the health score and the stage redesign each declined as out of scope and routed elsewhere, and the closed-won ambiguity flagged as a gating input the clock depends on.",
      "files": [],
      "expectations": [
        "Scopes the engagement to the handoff and names the other three requests explicitly as non-goals",
        "Declines to build the 30/60/90 onboarding plan, stating the handoff's job ends once the post-sale owner has received the customer and the first-value clock is running",
        "Declines to build the account health score and notes health scoring is a separate job that starts from the packet this process defines",
        "Takes closed-won entry criteria as a given input rather than redesigning pipeline stages inside this work",
        "Points the closed-won stage problem to a separate pipeline stage-definition audit",
        "Notes the internal clock must not start on a deal marked closed-won before it meets the stage's entry criteria, because a gate on a mislabeled deal measures nothing",
        "Notes that a phased 30/60/90 outline may be presented at kickoff while building and running it stays outside this process",
        "Carries the non-goals onto the Scope line of the emitted handoff spec",
        "Still delivers the handoff spec rather than refusing the request as a whole",
        "Keeps early-life churn in the design as a downstream outcome measure of handoff quality while still keeping health scoring itself out of scope"
      ]
    },
    {
      "id": 9,
      "prompt": "Steinmark Robotics, mid-market B2B, 30 deals a month. Our handoff SLA dashboard reports 'kickoff scheduled within 5 business days: 94%' and an average time-to-kickoff of 6.2 days, and sales leadership is delighted. Privately two of my CSMs say roughly half the kickoffs get moved at least once after they're booked, and one told me a customer no-showed twice and it never showed up anywhere. Separately, our reps sometimes flip deals to Closed Won before signature. What else should we be measuring?",
      "expected_output": "A rebuild of the measurement layer: the clock stops at kickoff held not scheduled, median and p90 replace the average, reschedules and no-shows tracked separately, two clocks defined, and the required timestamp list named.",
      "files": [],
      "expectations": [
        "Rejects 'kickoff scheduled' as the stopping point and requires the external clock to stop at kickoff held",
        "Explains that a scheduled-then-slipped kickoff is indistinguishable from no kickoff from the customer's point of view",
        "Requires kickoff no-shows and reschedules tracked separately from the clock itself",
        "Replaces the reported average with median and p90",
        "States that the p90 tail is where customers ghost",
        "Splits measurement into two clocks: closed-won to internal handoff, and acceptance to kickoff held",
        "Sets the internal handoff default at about 1 business day and the mid-market kickoff-held SLA at about 5 business days",
        "Requires both clocks measured in business hours or days from CRM timestamps rather than from recollection",
        "States the internal clock must not start on a deal flipped to Closed Won before it meets the stage's entry criteria",
        "Names the timestamps that must exist: closed-won, packet submitted, receiver assigned, accepted or rejected with a reason code, kickoff scheduled, kickoff held, and value event reached",
        "States that a KPI whose timestamp cannot be captured is fiction",
        "Escalates the external clock to both managers at 50% of the SLA elapsed with no kickoff yet scheduled"
      ]
    },
    {
      "id": 10,
      "prompt": "Marbrook Software, 45 deals a month, mid-market. Today when a deal closes the AE posts a summary in our #wins Slack channel, tags the CS lead, and emails the assigned CSM a recap. CSMs then dig through forwarded email threads before every kickoff to work out what was actually sold and promised. Two things also keep happening: new customers stay in our outbound prospecting sequences and keep getting 'have you considered Marbrook?' emails for weeks after signing, and a couple of handoffs last quarter landed in the CS inbox with nobody picking them up for over a week. Can you write us a better handoff email template and a cleaner Slack post format?",
      "expected_output": "A refusal to make chat or email the record, replaced by structured CRM fields with linked recordings, a fallback-owner assignment rule, a must-block gate, and trigger automation that removes the contact from sales sequences.",
      "files": [],
      "expectations": [
        "Declines to make chat or email the artifact of record, and does not deliver a Slack post format or email template as the deliverable",
        "Explains that context living in chat or email does not travel and cannot be gated",
        "Makes structured CRM fields the artifact of record for this motion, with linked call recordings carrying the nuance",
        "Allows chat and email only as notification channels, never as the record",
        "Diagnoses the CSM digging through email threads as free-text notes being the only artifact",
        "Adds removal of the contact from all sales sequences to the automation fired at the trigger",
        "Lists the other trigger automations: assign the receiver, notify them, create the kickoff task, and enroll the customer in the segment's post-sale sequence",
        "Adds an assignment rule with a named fallback owner so no handoff lands in a pooled inbox with nobody accountable",
        "Adds a must-block field gate so a handoff with an unwritten packet cannot fire at all",
        "Includes an Automation line in the emitted handoff spec",
        "States that free text is the fallback and never the plan, and that anything measured or gated must be a structured field"
      ]
    }
  ],
  "trigger_queries": [
    { "query": "design our sales to CS handoff process", "should_trigger": true },
    { "query": "what should transfer from the AE to the CSM when a deal closes", "should_trigger": true },
    { "query": "our CSMs start from zero on every single new account", "should_trigger": true },
    { "query": "customers keep repeating themselves to us after they sign", "should_trigger": true },
    { "query": "how do we stop new customers ghosting us during onboarding", "should_trigger": true },
    { "query": "we need SLAs between closed won and the kickoff call", "should_trigger": true },
    { "query": "build a handoff spec with an acceptance gate", "should_trigger": true },
    { "query": "post-close transition process for a B2B SaaS company", "should_trigger": true },
    { "query": "kickoffs happen anywhere from 3 days to 5 weeks after signature, help", "should_trigger": true },
    { "query": "who should own the customer once the contract is signed", "should_trigger": true },
    { "query": "what does a handoff even mean for a PLG company with pooled CS", "should_trigger": true },
    { "query": "our AEs promise things during the sale that nobody in CS knows about", "should_trigger": true },
    { "query": "closed won to kickoff process design", "should_trigger": true },
    { "query": "we want CS to be able to reject a bad handoff from sales", "should_trigger": true },
    { "query": "how long should it take to get a new customer into a kickoff meeting", "should_trigger": true },
    { "query": "our reps dump the deal in Slack when it closes and move on", "should_trigger": true },
    { "query": "define the fields a rep must fill before a deal can be passed over", "should_trigger": true },
    { "query": "what should be in a customer handoff packet", "should_trigger": true },
    { "query": "onboarding never knows what was actually sold", "should_trigger": true },
    { "query": "sales and CS blame each other every time a new customer churns early", "should_trigger": true },
    { "query": "we lose all momentum between signature and first value", "should_trigger": true },
    { "query": "process for introducing the CSM to the customer properly", "should_trigger": true },
    { "query": "how do we make sure the CSM has read the deal context before kickoff", "should_trigger": true },
    { "query": "new customers keep getting our prospecting emails after they buy", "should_trigger": true },
    { "query": "what should fire automatically when an opportunity goes closed won", "should_trigger": true },
    { "query": "our self-serve conversions just disappear into the product, what should happen next", "should_trigger": true },
    { "query": "we need a gate on closed won deals before they reach customer success", "should_trigger": true },
    { "query": "nobody is accountable for the customer between signature and onboarding", "should_trigger": true },
    { "query": "what should the AE hand over and what can we safely skip", "should_trigger": true },
    { "query": "design a kickoff meeting pattern for our mid-market deals", "should_trigger": true },
    { "query": "the CSM does archaeology in old email threads before every kickoff", "should_trigger": true },
    { "query": "make the sales to customer success transition less painful", "should_trigger": true },
    { "query": "reason codes for rejecting a handoff", "should_trigger": true },
    { "query": "measure how long it takes from closed won to first value", "should_trigger": true },
    { "query": "our handoff dashboard is all green but customers still complain", "should_trigger": true },
    { "query": "should we assign every new paying self-serve account to a human", "should_trigger": true },
    { "query": "we run the same post-sale process for enterprise and SMB, is that wrong", "should_trigger": true },
    { "query": "customers find out weeks after signing that a module was not included", "should_trigger": true },
    { "query": "we are growing fast and our post-sale handover is completely ad hoc", "should_trigger": true },
    { "query": "what data does customer success actually need from sales", "should_trigger": true },
    { "query": "set up accountability so deals do not sit unassigned after they close", "should_trigger": true },
    { "query": "how do we transfer a customer without them feeling a seam", "should_trigger": true },
    { "query": "revops project: fix the gap between closing a deal and onboarding starting", "should_trigger": true },
    { "query": "is a per-deal handover document worth it at 40 deals a month", "should_trigger": true },
    { "query": "we have no record of what was promised during the sale and it is costing us renewals", "should_trigger": true },
    { "query": "define the two clocks for our post-sale process", "should_trigger": true },
    { "query": "help me write the rules for when a deal is ready to go to CS", "should_trigger": true },
    { "query": "nobody owns the customer in the two weeks after they sign", "should_trigger": true },
    { "query": "what should trigger onboarding for a B2C subscription signup", "should_trigger": true },
    { "query": "design an internal briefing between the rep and the CSM", "should_trigger": true },
    { "query": "build a customer health score with weights and bands", "should_trigger": false },
    { "query": "our green accounts keep churning anyway", "should_trigger": false },
    { "query": "which leading indicators actually predict churn for us", "should_trigger": false },
    { "query": "is champion departure a reliable churn signal", "should_trigger": false },
    { "query": "build an early warning system for at-risk accounts", "should_trigger": false },
    { "query": "audit our pipeline stage definitions against buyer-verifiable milestones", "should_trigger": false },
    { "query": "our stages are named after rep activity like demo scheduled and proposal sent", "should_trigger": false },
    { "query": "why is everything stuck in one pipeline stage", "should_trigger": false },
    { "query": "design our revenue funnel stage set from scratch", "should_trigger": false },
    { "query": "marketing to sales handoff design", "should_trigger": false },
    { "query": "define MQL to SQL to opportunity for us", "should_trigger": false },
    { "query": "our round robin is lopsided, fix our lead assignment", "should_trigger": false },
    { "query": "route inbound leads to reps by territory and segment", "should_trigger": false },
    { "query": "who should get this inbound lead", "should_trigger": false },
    { "query": "our MQL threshold is wrong and sales rejects everything we send", "should_trigger": false },
    { "query": "design a lead scoring model with fit and engagement signals", "should_trigger": false },
    { "query": "who owns each CRM field and how often must it be refreshed", "should_trigger": false },
    { "query": "our CRM fields contradict each other", "should_trigger": false },
    { "query": "finance and sales report two different ARR numbers", "should_trigger": false },
    { "query": "which system is source of truth for the account object", "should_trigger": false },
    { "query": "design our deal desk discount approval matrix", "should_trigger": false },
    { "query": "approval chain for non-standard payment terms", "should_trigger": false },
    { "query": "where are we losing deals in the funnel and what is it worth", "should_trigger": false },
    { "query": "size our revenue leakage in recoverable dollars", "should_trigger": false },
    { "query": "build a KPI tree from the board down to IC level", "should_trigger": false },
    { "query": "what should our north star metric be", "should_trigger": false },
    { "query": "structure the revenue section of our board deck", "should_trigger": false },
    { "query": "why did we miss the number last quarter", "should_trigger": false },
    { "query": "our reps are sandbagging the forecast", "should_trigger": false },
    { "query": "clean up stale deals before the QBR", "should_trigger": false },
    { "query": "deals keep pushing their close date out", "should_trigger": false },
    { "query": "we have too many GTM tools, help us consolidate the stack", "should_trigger": false },
    { "query": "how do I break into RevOps", "should_trigger": false },
    { "query": "interview questions for a sales ops manager hire", "should_trigger": false },
    { "query": "write a 30-60-90 ramp plan for our new ops hire", "should_trigger": false },
    { "query": "which revops newsletters and podcasts should I follow", "should_trigger": false },
    { "query": "design our customer onboarding curriculum for the first 90 days", "should_trigger": false },
    { "query": "write a welcome email sequence for new customers", "should_trigger": false },
    { "query": "design onboarding for our newly hired sales reps", "should_trigger": false },
    { "query": "build a QBR template for our CSMs to run with accounts", "should_trigger": false },
    { "query": "renewal playbook for 90 days before contract expiry", "should_trigger": false },
    { "query": "expansion and upsell playbook for existing accounts", "should_trigger": false },
    { "query": "set up an NPS survey program for our customers", "should_trigger": false },
    { "query": "how many accounts should each CSM carry", "should_trigger": false },
    { "query": "escalation matrix for support tickets", "should_trigger": false },
    { "query": "our support ticket routing is broken", "should_trigger": false },
    { "query": "engineering to on-call support handover process", "should_trigger": false },
    { "query": "shift handover checklist for our operations centre", "should_trigger": false },
    { "query": "write an SOW template for our professional services team", "should_trigger": false },
    { "query": "implementation project plan template for a new customer", "should_trigger": false }
  ]
}

# Handoff Packet Fields

The data set that must transfer at handoff merges the three best-known practitioner inventories, organized here into six categories:

- Kristi Faltorusso's "10 Essentials" checklist.
- Lincoln Murphy's Sixteen Ventures list: CRM data, call recordings, notes, contract terms, goals, concerns, timeline expectations, the customer's own definition of success.
- Gainsight's operationalized set: primary business objective, buying-process engagement history, feature interests, contract details, value areas.

Rules that make the list work:

- Split gate handling by field weight. Blocking everything guarantees the gate gets gamed.
  - **Must-block**: gate refuses the handoff without it.
  - **Optional**: valuable, never blocking.
- Every field names a role on each side. Cut any field with no consumer.
  - **Supplier**: the role that fills it, usually during the sales cycle, not in a panic at close.
  - **Consumer**: the role that reads it at internal sync or kickoff.
- Prefer structured fields for anything measured or gated. Attach recordings and documents for anything with nuance. Free text is the fallback, never the plan. Murphy's warning: the discovery intel that never leaves the rep's head is exactly what loses the emotional connection.
- Right-size per segment: the full set below fits enterprise/high-touch; see segment guidance at the end for what SMB and self-serve keep.

## 1. Commercial and contract

| Field                                                           | Why it transfers                                                                                            | Supplier        |
| --------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | --------------- |
| Products/modules purchased, and exclusions                      | The receiver must know what was actually bought - and what the customer may believe they bought but did not | AE (must-block) |
| Contract value, term, start date, renewal date                  | Sets the renewal clock and coverage tier                                                                    | AE (must-block) |
| Special terms: non-standard renewal, pricing, payment, opt-outs | Non-standard terms surprise post-sale teams at the worst moment                                             | AE (must-block) |
| Discount given and rationale                                    | Context for renewal conversations; deep discounts flag expectation risk                                     | AE (optional)   |

## 2. Goals and success definition

| Field                                                                                    | Why it transfers                                                                                                                          | Supplier                       |
| ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ |
| Primary business objective(s) for buying                                                 | The single most-cited field across all three practitioner lists; everything post-sale aligns to it                                        | AE from discovery (must-block) |
| Customer's own definition of success, with metrics/KPIs agreed                           | Murphy's Desired Outcome = Goal + Appropriate Experience: carry the goal _and_ the experience-delivery expectation, not just the contract | AE (must-block)                |
| Timeline expectations set during the sale                                                | Missed timeline expectations read as broken promises                                                                                      | AE (must-block)                |
| Conditions and constraints around the goal (budget cycle, exec mandate, deadline driver) | Explains urgency and sequencing to the receiver                                                                                           | AE (optional)                  |

## 3. Stakeholders and org

| Field                                                           | Why it transfers                                                                                                                         | Supplier        |
| --------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | --------------- |
| Economic buyer / signer                                         | Renewal authority; may never appear in onboarding otherwise                                                                              | AE (must-block) |
| Champion and day-to-day contact(s)                              | Who the post-sale owner actually works with                                                                                              | AE (must-block) |
| End-user groups and influencers, with sentiment per stakeholder | Faltorusso's list is explicit: stakeholders _with sentiment_ - a skeptical influencer is a different onboarding than an enthusiastic one | AE (optional)   |
| Org chart overview: reporting lines, dotted lines               | Locates the champion's power and the expansion paths                                                                                     | AE (optional)   |

## 4. Sales-cycle context

| Field                                                                                           | Why it transfers                                                                                                  | Supplier        |
| ----------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | --------------- |
| Use cases and pain points that resonated                                                        | Onboarding should land first value on the pain that sold the deal, not a generic tour                             | AE (must-block) |
| Competitive evaluation: who else was evaluated, why this vendor won                             | The win reason is the retention thesis; the losing vendor will call again                                         | AE (optional)   |
| Concerns and objections raised during the sale                                                  | Unaddressed concerns resurface as churn signals                                                                   | AE (must-block) |
| Commitments and promises made: SLAs, training, custom work, roadmap items, support expectations | Hidden promises discovered post-signature are the classic handoff failure; reviewed line by line at internal sync | AE (must-block) |

## 5. Technical and delivery requirements

| Field                                                 | Why it transfers                              | Supplier                                           |
| ----------------------------------------------------- | --------------------------------------------- | -------------------------------------------------- |
| Integrations, APIs, custom development needed         | Sizing and sequencing the implementation      | AE / sales engineer (must-block when any exist)    |
| SOW ownership and delivery timeline, if services sold | Who delivers what by when                     | AE / services (must-block when SOW exists)         |
| Security, compliance, data-residency requirements     | Late discovery blocks go-live                 | Sales engineer (optional unless regulated segment) |
| Data migration scope                                  | Often the longest pole in time-to-first-value | Sales engineer (optional)                          |

## 6. Engagement history

| Field                                              | Why it transfers                                                                   | Supplier                                                     |
| -------------------------------------------------- | ---------------------------------------------------------------------------------- | ------------------------------------------------------------ |
| Key call recordings and demo recordings, linked    | The highest-fidelity carrier of nuance; cheaper than perfect notes                 | Auto-captured where tooling exists, else AE links (optional) |
| Content/webinar engagement from the buying process | Gainsight's operational set: shows what topics the buying team already cares about | Marketing automation (optional)                              |
| Feature/module interests expressed pre-sale        | Directs which capabilities to activate first                                       | AE (optional)                                                |

## Right-sizing by segment

- **Enterprise/high-touch**: full set; categories 3-5 carry the weight.
- **Mid-market**: full must-block set; optional fields filled when known, never chased.
- **High-volume SMB**: categories 1, 2, and the commitments field only, as structured CRM fields - a packet document per deal does not scale here.
- **PLG/self-serve and B2C**: the "packet" is the account record itself - plan, billing state, signup source, activation signals, marketing consent. Human-context fields are irrelevant; completeness of the record is the gate.

# Segment Variants

The governing principle is Lincoln Murphy's Appropriate Experience (AX)-based segmentation: set the touch level by the experience a segment needs to feel successful, never by what it pays. Segment the handoff by needed experience and operational capability, with price as a constraint, not the driver.

Two consequences invert naive defaults:

- Over-serving self-serve customers with human touch is itself a bad experience ("smaller customers may need a lot, but self-service and 1:many is what they expect").
- A large, mature customer may need less hand-holding than assumed ("bigger more mature customers may not need much from us at all").

## Summary table

Columns run from most ceremony to least; that is a segment ordering, not a build order. The build order inside any one column is the efficiency ranking in the skill's Ceremony, Ranked section - build wiring first everywhere, then add rungs until the segment's hour ceiling runs out. The last two rows are that ceiling and what it buys.

| Design decision      | Enterprise / high-touch                                           | Mid-market                                            | High-volume SMB                                     | PLG / self-serve                                    | B2C subscription                                               |
| -------------------- | ----------------------------------------------------------------- | ----------------------------------------------------- | --------------------------------------------------- | --------------------------------------------------- | -------------------------------------------------------------- |
| Trigger              | Closed-won, gated on full packet + SOW                            | Closed-won, gated on must-block fields                | Closed-won, gated on structured fields only         | Conversion/plan-change event in billing             | Subscription-start event in billing                            |
| Artifact             | Packet document + CRM fields + recordings                         | CRM fields + short packet                             | CRM fields only                                     | Event payload on account record                     | Event payload on customer record                               |
| Receiver             | Named CSM + implementation team                                   | Named CSM (or onboarding pool → CSM)                  | Pooled CS, assignment rule                          | No human; lifecycle system owns it                  | No human; lifecycle system owns it                             |
| Meetings             | Internal sync + live customer kickoff                             | Internal sync (async brief acceptable) + kickoff call | No internal meeting; welcome call optional          | None; activation flow instead                       | None; lifecycle messaging instead                              |
| Internal clock       | 1 business day                                                    | 1 business day                                        | Same day (automated assignment)                     | Instant (event-driven)                              | Instant (event-driven)                                         |
| External clock       | Kickoff held ≤ 10 business days                                   | Kickoff held ≤ 5 business days                        | First touch ≤ 2 business days                       | First automated touch ≤ 1 hour                      | First automated touch ≤ 1 hour                                 |
| Acceptance           | CSM accepts/rejects explicitly                                    | CSM accepts/rejects explicitly                        | Sampling audit instead of per-deal acceptance       | Automated validation of record completeness         | Automated validation of record completeness                    |
| CS hours per handoff | Several hours, across two meetings and a document                 | About an hour, one meeting plus a short packet        | Minutes, and none on most deals                     | Near-zero; hours spent once on the motion map       | Near-zero; hours spent once on the motion map                  |
| Retention bought     | Ghosting prevented on accounts whose loss is individually visible | Momentum held between signature and first value       | Repeat-yourself and archaeology removed at scale    | A reliable path to the activation event             | A reliable path to the activation event, within consent limits |
| Rungs deleted        | None                                                              | Packet document, unless services ship with the deal   | Per-deal acceptance, internal sync, packet document | Both meetings, packet document, per-deal acceptance | Both meetings, packet document, per-deal acceptance            |

Clock values are starting defaults to calibrate against the org's baseline, not published standards. Hour figures are orders of magnitude for sizing the ceremony, not measured averages - measure the org's own before treating them as a budget.

The rungs in the deleted row are deleted, not deprioritized: a segment that keeps them on a backlog re-acquires them the first time a deal goes badly, and the volume that made them unaffordable has not changed.

## Enterprise / high-touch

Multi-person transfer at the internal sync:

- Rep briefs CSM and implementation/services together.
- Commitments and SOW reviewed line by line before any customer contact.

The customer kickoff is a formal, visible transfer - sales introduces the post-sale owner live and stays engaged until CS accepts, because the customer must never wonder who owns them now. A phased 30/60/90 outline is _presented_ at kickoff, but building and running it belongs to onboarding, not to this process.

## Mid-market

Same shape, lighter weight: the internal sync can be an async written brief with a confirmation step when calendars don't allow a meeting, but the acceptance step stays explicit - this is the segment where "we skipped the sync just this once" quietly becomes the norm.

- One named receiver per deal.
- Kickoff within a week keeps momentum from the buying decision.

## High-volume SMB

Volume kills per-deal ceremony:

- Structured CRM fields are the whole artifact.
- Assignment is rule-driven into a pool with a fallback owner.
- The welcome touch is a templated call or email sequence.

Per-deal acceptance is replaced by a weekly sampling audit of packet quality plus automated completeness checks - the gate still blocks, but a human no longer inspects every deal.

## PLG / self-serve

There is no human handoff, by design - do not invent one. The handoff is a system-to-system event: a billing or CRM state change (trial converts, plan upgrades, team crosses a seat threshold) that must fire reliably and carry a complete account record. The design questions become:

- **Which signals trigger which automated motion**:
  - Conversion → lifecycle onboarding sequence and in-app guidance toward the activation event (the behavioral moment that predicts retention - identify it and design the shortest path to it).
  - Usage threshold → expansion motion.
  - Silence past a defined window → re-engagement motion.
- **Who owns exceptions**: pooled, reactive CS (or support) receives the cases automation escalates - failed activation after N days, high-value account inactive, billing failure. Ownership of the motion map itself typically sits with growth or lifecycle marketing, not CS - name the owner explicitly either way.
- **What the gate checks**: record completeness (plan, billing state, consent, attribution), because a malformed record silently breaks every downstream motion.

The substitutes for the human motion:

- The activation event stands in for the kickoff.
- Time-to-activation stands in for time-to-kickoff.

## B2C subscription

Mechanically the PLG pattern - system-triggered lifecycle onboarding, no human owner, pooled exception handling - with three differences worth designing for:

- Consent and privacy constraints gate which lifecycle messages may fire at all.
- Involuntary-churn handling (failed payments, dunning) enters the exception map immediately because the payment relationship starts at day zero.
- The "stakeholder" model collapses to one person, so all context is behavioral, not relational.

Everything else transfers unchanged.

## Mixed-motion orgs

Most orgs run two or three of these at once. Write one spec with per-segment rows for trigger, artifact, clocks, meetings, and acceptance - not separate specs - so the segments share the gate logic, the reason codes, and the KPI definitions, and deals that cross segments (a self-serve account converting to sales-led) inherit a defined path.

# SLAs, the Acceptance Gate, and KPIs

Every handoff between teams needs an SLA, a tracking mechanism, and someone accountable for follow-through - the widely repeated RevOps rule applies to sales-to-CS exactly as it does to marketing-to-sales. This file defines the two clocks, the acceptance mechanics, and the measurement layer.

## The two clocks

| Clock            | Starts                       | Stops                                                                       | Default target                                                                           |
| ---------------- | ---------------------------- | --------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| Internal handoff | Closed-won recorded in CRM   | Packet submitted, receiver assigned, receiver notified                      | 1 business day (same day for automated segments)                                         |
| External kickoff | Receiver accepts the handoff | Kickoff meeting _held_ (not scheduled) - or first automated touch delivered | Segment SLA: ≤ 10 business days high-touch, ≤ 5 mid-market, ≤ 2 SMB, ≤ 1 hour self-serve |

Rules:

- Measure in business hours/days from CRM timestamps, never from recollection. Report median **and** 90th percentile - the p90 tail is where customers ghost.
- The external clock stops at _held_, because a scheduled-then-slipped kickoff is indistinguishable from no kickoff to the customer. Track kickoff no-shows and reschedules separately.
- The internal clock does not start until the deal is genuinely closed-won per the stage's entry criteria - a gate on a mislabeled deal measures nothing.
- Defaults above are this skill's starting conventions; calibrate against the org's own baseline within the first quarter.

## The acceptance gate

The step that turns the handoff from a notification into a contract between teams.

1. **Submit**: rep completes the packet; the gate auto-checks must-block fields and required attachments. Incomplete submissions bounce immediately without starting the receiver's clock.
2. **Review**: the receiver (CSM, pool lead, or automated validator) reviews within a defined window - default 1 business day.
3. **Accept or reject**: acceptance transfers ownership and starts the external clock. Rejection carries a reason code and bounces to the rep with a re-submission clock (default 1 business day). A reject is a quality signal, never a fault ruling - no penalty for rejecting, or the gate becomes theater.
4. **Re-submission**: second submission reviewed against the cited reason only. A second reject on the same deal escalates automatically.

Starting reason codes (extend from observed rejects, retire unused ones quarterly):

| Code     | Meaning                                                                                                         |
| -------- | --------------------------------------------------------------------------------------------------------------- |
| INC-COM  | Commercial/contract fields incomplete or contradict the contract                                                |
| INC-GOAL | Business objective or success definition missing or generic boilerplate                                         |
| INC-STK  | Economic buyer or day-to-day contact missing                                                                    |
| INC-TECH | Known technical/delivery requirement undocumented                                                               |
| UND-PROM | Commitment made to the customer not recorded in the packet                                                      |
| BAD-FIT  | Customer appears outside the qualified-customer definition - routes to the alignment forum, not back to the rep |
| JUNK     | Fields filled with throwaway non-answers just to pass the gate                                                  |

## Escalation

| Situation                | Escalates to             | When                                          |
| ------------------------ | ------------------------ | --------------------------------------------- |
| Internal clock breached  | Rep's manager            | At 100% of SLA elapsed                        |
| Review window breached   | CS/pool manager          | At 100% of SLA elapsed                        |
| External clock at risk   | Both managers            | At 50% elapsed with no kickoff scheduled      |
| Second reject, same deal | Both managers jointly    | Immediately                                   |
| BAD-FIT code used        | Sales/CS alignment forum | Next session, with the deal as an agenda item |

## KPIs

| KPI                         | Definition                                                                    | Starting target         | Caveat                                                                                                                                                                                     |
| --------------------------- | ----------------------------------------------------------------------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Gate completeness           | % of closed-won deals passing the gate complete on first submission           | ≥ 95%                   | Measures presence, not quality - pair with the sampling audit                                                                                                                              |
| First-submission acceptance | % of handoffs accepted without a reject                                       | ≥ 90%                   | Near-100% alongside quality complaints means the gate checks the wrong fields                                                                                                              |
| Internal handoff time       | Closed-won → submitted+assigned, median and p90                               | Median ≤ 1 business day |                                                                                                                                                                                            |
| Kickoff time                | Acceptance → kickoff held, median and p90, per segment                        | Within segment SLA      | Stops at held, not scheduled                                                                                                                                                               |
| Time to First Value (TTFV)  | Close → customer gets real value or clearly sees the value potential (Murphy) | Measured; trending down | A goal, not a stopwatch: "a customer should NOT be considered 'onboard' simply after a certain amount of time has passed" - define the value event, don't let elapsed time stand in for it |
| Early-life churn            | Churn/non-renewal within first 90 days                                        | Tracked as outcome      | Downstream measure of handoff quality; never target-managed weekly, and shared ownership with onboarding                                                                                   |
| Reject-code distribution    | Rejects by reason code per month                                              | Reviewed monthly        | A recurring code is the packet definition asking to be changed                                                                                                                             |

Targets are this skill's conventions, set where a lower bar would not survive real deal flow - not published industry benchmarks. Iterate the gate, packet, and clocks until all hold on a rolling month.

## Instrumentation and cadence

- Timestamps: closed-won, packet submitted, receiver assigned, accepted/rejected (+code), kickoff scheduled, kickoff held, value event reached. All as CRM fields or workflow logs - if a timestamp can't be captured, the KPI on it is fiction.
- Automation at trigger: assign receiver, notify, create kickoff task, enroll in the segment's sequence, remove the contact from all sales sequences (the classic miss - the customer keeps getting prospecting emails after buying).
- Cadence:
  - Weekly during pilot: review every reject and every SLA breach individually.
  - Monthly in steady state: KPI dashboard, reject-code distribution, packet-quality sample of 5-10 deals.
  - Quarterly: re-fit reason codes, re-check must-block field list against what kickoffs actually used, recalibrate targets against the new baseline.

# Worked Examples

Three artifacts: a filled handoff spec for a mixed-motion org, a filled packet for one deal, and a negative example with its cost. Company names and figures are illustrative.

## Example 1: Filled handoff spec (mid-market + self-serve SaaS)

```
HANDOFF SPEC - Northbeam Analytics, 2026-03-02, v1
Scope      : mid-market sales-led (~25 deals/mo) + self-serve (~400 conversions/mo).
             Non-goals: onboarding curriculum, 90-day success plans, health scoring.
Trigger    : Mid-market - opportunity set to Closed Won with signed contract attached.
             Gate blocks on: products+exclusions, ACV/term/renewal date, special terms,
             business objective, success metrics, timeline expectations, economic buyer,
             day-to-day contact, resonating use cases, concerns raised, commitments log,
             integrations list (if any). Self-serve - billing event `subscription.created`;
             gate blocks on plan, billing state, signup source, marketing consent.
Packet     : Mid-market - CRM fields above + 1-page brief + links to 2 key call recordings.
             Self-serve - the account record is the packet.
Artifact   : CRM record of the opportunity (fields) + attached brief. Event payload for
             self-serve. Chat and email are never the record.
Clocks     : Mid-market - internal ≤ 1 business day; kickoff held ≤ 5 business days after
             acceptance. Self-serve - assignment instant; first lifecycle email ≤ 1 hour.
Meetings   : Mid-market - async internal brief with CSM confirmation, then customer
             kickoff where the AE introduces the CSM live. Self-serve - none; activation
             flow targets "first dashboard shared" as the activation event.
Acceptance : Mid-market - receiving CSM accepts/rejects ≤ 1 business day, reason-coded;
             re-submission ≤ 1 business day; second reject escalates to both managers.
             Self-serve - automated record validation; failures queue to CS ops.
Escalation : SLA breach -> owning manager at 100% elapsed; kickoff at risk -> both
             managers at 50% elapsed unscheduled; BAD-FIT -> monthly alignment forum.
Automation : On trigger: assign CSM by segment rule (fallback: pool lead), notify, create
             kickoff task, enroll in "New Customer" sequence, remove contact from all
             sales sequences, set Customer Since date.
KPIs       : Gate completeness ≥95% | first-submission acceptance ≥90% | internal median
             ≤1 bd | kickoff median ≤5 bd (p90 reported) | TTFV to "first dashboard
             shared" trending down | 90-day churn tracked as outcome | reject codes monthly.
Governance : Process owner: RevOps lead. Acting: AEs (supply), CSMs (accept/receive),
             CS ops (self-serve validation). Review: weekly during 60-day pilot, then
             monthly. Change log: spec doc revision history.
```

## Example 2: Filled handoff packet (one mid-market deal)

```
HANDOFF PACKET - Harwell Logistics, closed-won 2026-03-10, AE: R. Okafor -> CSM: L. Deme
Commercial : Platform (Growth tier, 40 seats) + Routing module. EXCLUDED: forecasting
             module (demoed, not bought - customer may assume otherwise). $58k ACV,
             12 months, renewal 2027-03-10. Special: net-60 payment, 30-day opt-out
             clause at month 6. 12% discount for case-study participation commitment.
Objective  : Cut delivery-window misses from 9% to under 4% before their Q4 peak season.
Success    : Agreed metric: delivery-window miss rate in their weekly ops report.
             They consider it working when their own dashboard shows <6% by end of Q2.
Timeline   : Live before 2026-05-01 - hard expectation, tied to a board commitment.
Stakeholders: Economic buyer: COO T. Harwell (signed, will not attend onboarding).
             Champion/day-to-day: Ops Director M. Chen (enthusiastic). Skeptic: IT lead
             J. Prieto - concerned about API load, needs early technical win.
Context    : Resonated: exception-alerting demo on their own sample data. Evaluated
             CompetitorX (lost on implementation time) - they will re-engage at renewal.
             Concerns raised: data accuracy of carrier feeds; prior vendor failed here.
Commitments: (1) Dedicated onboarding call with IT lead in week 1. (2) Carrier-feed
             accuracy review at day 30. (3) Case study drafted only after Q2 metric hit.
Technical  : TMS integration via REST API (their side, IT lead owns); no SOW; SSO required
             before company-wide rollout.
Recordings : Discovery call 2026-01-22, technical deep-dive 2026-02-18 (links in CRM).
```

## Example 3: Negative example - the handoff that wasn't

The same deal, as it actually happens in orgs with no designed process:

The AE marks the deal closed-won on the 10th, posts "Harwell signed! 58k!" in chat, and moves to the next deal. The CRM holds the contract PDF and a notes field reading "good discovery, ops pain, IT guy difficult." No assignment fires.

The CS manager notices the win in the revenue dashboard four days later and assigns whichever CSM has capacity. The CSM books a kickoff for week three - the earliest slot - and prepares by reading the notes field.

At kickoff, the CSM asks Harwell to describe their goals. M. Chen repeats the entire discovery conversation, visibly annoyed. Nobody knows about the week-1 IT call commitment, so J. Prieto - the skeptic - gets no early technical win and goes cold.

The forecasting-module exclusion surfaces in week five as "wait, that's not included?" The 30-day carrier-feed review never happens because nobody knew it was promised; the accuracy concern resurfaces in month three as an escalation.

The customer exercises the month-6 opt-out. Sales blames onboarding; CS blames the deal.

What it cost, in the terms this skill measures:

- Internal handoff 4 days instead of 1.
- Kickoff at 15 business days instead of 5.
- Two recorded commitments dropped (both were in a call recording nobody linked).
- TTFV never reached.
- $58k churned at month 6, plus the case study that was part of the price.

Every failure maps to a missing spec line:

- Gate (exclusions, commitments).
- Assignment automation (4-day gap).
- Acceptance step (a reject for UND-PROM/INC-GOAL would have caught the notes field).
- The external clock (15 days unmeasured because it was untracked).

---
name: sales-to-cs-handoff
description: Design the sales-to-CS handoff process after a deal closes - what data transfers, when, in what artifact, and who is accountable - producing a handoff spec with a gated closed-won trigger, a required handoff packet, timing SLAs, a kickoff meeting pattern, and a CS acceptance/rejection step. For RevOps and Sales Ops designing and enforcing the process, not a CSM running one handoff. Use whenever the user mentions sales to CS handoff, post-close transition, closed-won to kickoff, handoff accountability, "the CSM starts from zero", or "customers repeat themselves after signing" - even if they never say "handoff". Covers B2B high-touch through PLG/self-serve and B2C subscription. Do NOT use for account health scoring - use mbfinotti/revops-skills@customer-health-score instead.
license: MIT
metadata:
  author: Maya-Beth Finotti
  version: "1.3.6"
---

# CS Handoff

Design the process that moves a customer from the seller who won them to the owner who keeps them. Lincoln Murphy's diagnosis frames the stakes: "Customers hate three things: surprises, uncertainty, and repeating themselves" - and a poor handoff delivers all three before the customer's first call with CS. He attributes customers ghosting during onboarding "100% of the time" to a poorly designed - or not-designed-at-all - sales handoff process.

The design job has six decisions:

- The trigger event and its gate.
- The required data set.
- The artifact it travels in.
- The timing clocks.
- The meeting pattern.
- An accountability chain with an explicit acceptance step.

The named canon, where it genuinely helps:

- **Winning by Design's Bowtie Model** places Commit at the center of one continuous revenue lifecycle - the handoff is the seam between its two halves, not the end of a funnel.
- **Murphy's Desired Outcome** (Goal + Appropriate Experience) defines what must transfer: the customer's actual goal _and_ the experience they need to feel successful, not just contract terms.
- **Murphy's touch-level segmentation** sets coverage by what a segment needs, never by what it pays.
- **Kristi Faltorusso's "10 Essentials"** checklist is the best-known practitioner inventory of the information that must move ("If you are aligned on all of these details, you will be set up to have a productive partnership kickoff").
- **Time to First Value** (TTFV, Murphy) is the clock that starts ticking at the handoff moment.

Boundaries, stated because readers expect them here:

- Not employee/new-hire onboarding - ramping a new internal hire is a different job entirely.
- Not the drafting of a single recap email.
- Not the post-kickoff onboarding curriculum or 90-day success plan - this skill's job ends when the customer is successfully received by the post-sale owner and the first-value clock is running.
- Not health scoring or churn-signal discovery (sibling skills own those), though early-life churn is a legitimate outcome measure for handoff quality.
- Not pipeline-stage redesign - closed-won entry criteria are a gating input here, taken as given.

## Interview

Ask before designing. One question per message; offer multiple-choice answers where possible. Skip anything already answered.

- Which motion(s), and the segment mix? (a) sales-led enterprise/high-touch, (b) mid-market, (c) high-volume SMB, (d) PLG/self-serve, (e) B2C subscription - often several at once.
- Who exists post-sale? (a) dedicated named CSM, (b) pooled CS, (c) implementation/onboarding team then CSM, (d) no human - automated lifecycle only.
- How many closed-won deals per month, per segment? (Decides how heavy the artifact and meeting pattern can afford to be.)
- Today, how long from closed-won to kickoff (or first lifecycle touch)? Is it even measured?
- What does the CRM actually capture at closed-won today - enforced required fields, call recordings, free-text notes only?
- Is the AE compensated or held accountable past close (clawback, onboarding milestone, required intro)? This decides how much the process can ask of sales.
- Who can block or accept a handoff today? Has CS ever rejected one?
- What breaks today - customers repeating themselves, ghosting, kickoff delays, CSMs doing archaeology in old email threads?
- By when must the improved handoff be live - this quarter's closes, or next fiscal year? A hard date promotes the wiring and the live kickoff and defers the packet document.
- One-off fix, or a compounding asset? A compounding mandate promotes the acceptance step, whose reject codes only start rewriting the packet from the second quarter on.
- The effort ceiling: how many customer-success hours per handoff can the receiving team actually spend, and does CS have the standing to reject a rep's work? A low hour ceiling deletes the packet document and the internal sync; no standing deletes the acceptance step until a manager sponsors it.

## Ceremony, Ranked

Five things a handoff process can buy, ranked by retention bought per hour of customer-success time. Build down the list and stop where the segment's hour ceiling runs out. The axes disagree, which is the point - the strongest rung and the cheapest rung are not the same rung.

- efficiency: wiring > live customer kickoff > internal sync > acceptance step > per-deal packet document
- value: live customer kickoff > internal sync > wiring > per-deal packet document > acceptance step
- effort (CS hours per handoff): per-deal packet document > live customer kickoff == internal sync > acceptance step > wiring

| Rung                                                                                                      | What it costs                                                                                                      | What it buys                                                                                                          |
| --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------- |
| **Wiring**: must-block field gate on structured CRM fields, plus an assignment rule with a fallback owner | A one-off configuration pass of days; near-zero per handoff after that                                             | Context exists at all and every handoff carries a name - kills both the repeat-yourself complaint and the archaeology |
| **Live customer kickoff** with a visible transfer of ownership                                            | About an hour of the receiver's time, plus scheduling against the customer's calendar; one attempt, not repeatable | The ghosting fix - the customer leaves the call knowing who owns them now                                             |
| **Internal sync** before any customer contact                                                             | About an hour across two internal calendars                                                                        | Commitments and nuance surface before the customer tests them                                                         |
| **Acceptance step** with reason codes                                                                     | Minutes of receiver time per deal, plus the political capital to let CS reject a rep's work                        | Proves the packet was read; reject codes compound into a better packet definition each quarter                        |
| **Per-deal packet document** plus recordings review                                                       | Hours per handoff, split between rep and receiver                                                                  | Fidelity structured fields cannot carry - realized only where implementation spans teams                              |

The `==` on effort is real: kickoff and sync each cost about an hour of the receiver's time. What separates them is coordination and reversibility, not hours - the kickoff runs against the customer's calendar and gets one attempt, which is why efficiency ranks it above the sync where raw hours cannot.

Default rung: wiring plus the live kickoff, in every segment where a human receives the customer.

- Add the internal sync when more than one internal team delivers, or when commitment-related reject codes keep recurring.
- Add the packet document only when implementation genuinely spans teams.

What this order starves: the full high-touch ceremony - packet document, internal sync, line-by-line commitments review - loses every efficiency round, because its value concentrates in the few deals that would otherwise have failed loudly while the average deal shows no return. Promote it whole, ratio ignored, when:

- Losing one account would visibly dent the segment's renewal base.
- Services or an SOW ship with the deal.
- Regulated data requirements are in play.

Delete a rung, never demote it.

- Above SMB volume, per-deal acceptance is deleted and replaced by the sampling audit in [references/segment-variants.md](references/segment-variants.md).
- In PLG/self-serve and B2C, both meetings and the packet document are deleted outright - no human receives the customer, so ranking human ceremony there is fiction.

A rung parked at the bottom of the list comes back later as scope.

This ordering is a default, not a law: it shifts with volume, with who executes it, and with what the Interview surfaced.

- AEs compensated past close make the sync and the packet cheap to demand and move both up.
- A CS team that has never rejected a handoff cannot start with the acceptance step whatever its ratio says.
- Call recording already auto-captured raises the packet document by stripping most of its cost.

Re-rank against those answers before proposing anything.

## Workflow

1. Run the Interview; collect every answer before designing.
2. Define the trigger and its gate. Take closed-won entry criteria from the stage definitions as given input - do not redesign stages here.
   - **Trigger**: the closed-won event as the CRM records it.
   - **Gate**: the set of blocking conditions (required packet fields complete, required attachments present) without which the handoff must not fire.
3. Define the required data set from [references/handoff-packet-fields.md](references/handoff-packet-fields.md). Give every field a named supplier and a named consumer, and cut any field nobody reads at kickoff - an unread field is gate friction with no return. Fill in this order, by retention bought per minute of rep time: auto-captured call recordings > goal and success definition > commitments made during the sale > commercial terms > stakeholders with sentiment > technical requirements > marketing engagement history.
   - Recordings lead because tooling fills them at near-zero rep cost and they carry the nuance no field does.
   - Engagement history costs a rep nothing to skip and almost nobody opens it.
   - Must-block the top four.
   - Leave the rest optional, and promote technical requirements to must-block in any segment where integrations or an SOW routinely exist.
4. Choose the artifact per segment. Never chat threads or email as the artifact of record - context that lives there does not travel and cannot be gated.
   - Structured CRM fields for every human motion.
   - A system event payload for automated ones.
   - The per-deal packet document only under the promotion condition in Ceremony, Ranked - it is the bottom rung, not the default.
5. Set the two clocks: closed-won to internal handoff, and internal handoff to external kickoff held (or first automated touch). Defaults per segment in [references/slas-and-kpis.md](references/slas-and-kpis.md).
6. Design the meeting pattern where a human motion exists, taking both meetings and their build order from Ceremony, Ranked. Both are common practice, not a named framework.
   - **Internal sync**: the rep briefing the post-sale owner before any customer contact.
   - **Kickoff**: sales introducing that owner live.

   The visible transfer is what the kickoff buys, because, as Murphy puts it, "Sales STILL holds the keys to the relationship" until the customer knows who owns them now.

7. Assign accountability: a named owner for every step, and - wherever volume leaves room for per-deal review - CS explicitly accepts or rejects each handoff against the gate. Above SMB volume, the sampling audit replaces this step entirely.
   - Rejects bounce back to the rep with a reason code and a re-submission clock.
   - They never sit in limbo with the customer waiting.
8. Wire escalation.
   - SLA breaches and repeat rejects escalate to named manager roles.
   - Suspected bad-fit deals route to the sales/CS alignment forum rather than being absorbed - "Bad fit is not a Customer Success problem" (Sixteen Ventures).
9. Instrument the KPIs from [references/slas-and-kpis.md](references/slas-and-kpis.md), measured from CRM timestamps and reason codes, not from memory.
10. Emit the spec (next section) section by section for user validation; ground it in the matching worked example from [references/worked-examples.md](references/worked-examples.md).
11. Pilot on one segment for a full cycle of deals, review weekly, then roll out. Review reject reason codes and KPI misses monthly - recurring reject reasons are the packet definition telling you it is wrong.
12. If your harness has persistent memory, memorize the approved spec - gate, packet fields, clocks, acceptance rules, owners - so later revisions and per-segment extensions start from it instead of re-interviewing. Without memory, tell the user to keep the spec document as the standing input for future runs.

## B2B and B2C

The core mechanics are identical in both, and say so when asked. They apply unchanged from enterprise B2B to consumer subscriptions:

- A gated trigger.
- A defined data set.
- An artifact of record.
- Two clocks.
- An accountable receiver.

What genuinely differs is whether a human receives the customer:

- **Sales-led B2B**: the transfer is relationship-heavy - live meetings, a named owner, discovery intel and stakeholder context dominating the packet.
- **PLG/self-serve and B2C subscription**: there is often no human handoff by design - Murphy argues no-touch customers "should just be left alone", because over-serving them with human touch is itself a bad experience. The handoff is a system-to-system event (a CRM or billing state change) that triggers automated lifecycle onboarding, and the design question becomes which signals trigger which automated motion, and who owns exceptions - typically pooled, reactive CS or a growth/lifecycle-marketing owner rather than a CSM. The gate becomes data completeness on the account record; an activation event stands in for the kickoff.

Full per-segment treatment in [references/segment-variants.md](references/segment-variants.md).

## The Handoff Spec

Deliver every engagement as this artifact - a document RevOps can enforce and both teams can be held to. Fully worked versions live in [references/worked-examples.md](references/worked-examples.md).

```
HANDOFF SPEC - <company>, <date>, v<n>
Scope      : segments covered | explicit non-goals (onboarding curriculum, health scoring)
Trigger    : closed-won event definition + gate (blocking fields, required attachments)
Packet     : fields by category -> supplier -> consumer | must-block vs optional
Artifact   : where the packet lives per segment (CRM record, doc, event payload)
Clocks     : closed-won -> internal handoff | -> kickoff held (or first auto touch), per segment
Meetings   : internal sync + customer kickoff pattern per segment | or automated motion map
Acceptance : who accepts | reject reason codes | bounce protocol | re-submission clock
Escalation : SLA-breach path | repeat-reject path | bad-fit path
Automation : events fired at trigger (owner assignment, sequence enrollment, task creation,
             removal from sales sequences)
KPIs       : gate completeness % | both clocks | first-submission acceptance % | TTFV |
             early-life churn (outcome only)
Governance : process owner | acting owners per step | review cadence | change log location
```

## Objective and Pass Threshold

No standards body publishes handoff thresholds; these floors are this skill's starting conventions - calibrate them against the org's own baseline before treating them as law, and iterate the spec until all of them hold:

- **Gate completeness**: at least 95% of closed-won deals pass the gate complete on first submission.
- **Acceptance**: CS accepts at least 90% of handoffs on first submission.
- **Clocks**: internal handoff within 1 business day of closed-won; kickoff held within the segment SLA (default 10 business days for high-touch; first automated touch within the hour for self-serve).
- **Outcomes watched, not target-managed**: TTFV median measured and not worsening; early-life churn (first 90 days) tracked as the handoff's downstream outcome.

Read the failures diagnostically:

- Completeness near 100% with low acceptance means the gate checks the wrong fields.
- High acceptance with late kickoffs means the problem is scheduling or capacity, not data.

Definitions and instrumentation in [references/slas-and-kpis.md](references/slas-and-kpis.md).

## Common Failure Modes

| Symptom                                                 | Root cause                                    | Fix                                                                                                        |
| ------------------------------------------------------- | --------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| Customer repeats context to every new face              | Packet not written, or written and never read | Gate blocks unwritten packets; acceptance step proves they were read                                       |
| Customer ghosts during onboarding                       | No visible transfer of ownership              | Live introduction at kickoff; sales stays engaged until CS accepts                                         |
| CSM does archaeology in email threads                   | Free-text notes are the only artifact         | Structured fields plus linked call recordings; chat/email never the record                                 |
| Promises surface after signature                        | No commitments field in the packet            | Capture every commitment (timeline, SLA, training, roadmap) as a must-block field; review at internal sync |
| CS accepts everything to keep the peace                 | Acceptance gate is theater                    | Reason-coded rejects, tracked and reviewed, with no penalty for rejecting                                  |
| Gate gamed with "N/A" in every field                    | Completeness measured as non-empty            | Spot-audit packet quality monthly; reject codes catch junk at acceptance                                   |
| Handoff fires into a pooled queue and vanishes          | No named receiver per handoff                 | Assignment rule with a fallback owner on every trigger                                                     |
| Self-serve volume forced through the enterprise process | One process designed for the largest deal     | Segment variants; automate everything below the human-touch line                                           |
| Bad-fit customers blamed on onboarding                  | No shared definition of a qualified customer  | Route to the sales/CS alignment forum; fix upstream in stage criteria                                      |

## Invocation Examples

- "Our CSMs start from zero on every new account and customers complain about repeating themselves - design a real sales-to-CS handoff process."
- "We close 60 deals a month across mid-market and self-serve; kickoffs happen anywhere from 3 days to 5 weeks after signature. Build the handoff spec with SLAs and an acceptance gate."
- "We're pure PLG with pooled CS - what does a handoff even mean for us, and what should trigger what?"

## Reference

- Read [references/handoff-packet-fields.md](references/handoff-packet-fields.md) when defining the data set - the field-by-field packet, grouped by category, with why each field transfers and who supplies it.
- Read [references/segment-variants.md](references/segment-variants.md) when the org spans motions - how trigger, artifact, timing, meetings, and ownership change from enterprise to B2C subscription.
- Read [references/slas-and-kpis.md](references/slas-and-kpis.md) when setting clocks and instrumentation - SLA defaults, the acceptance gate mechanics, reason codes, KPI definitions, and the review cadence.
- Read [references/worked-examples.md](references/worked-examples.md) when shaping the deliverable - a filled spec, a filled packet, and a negative example with its cost.
- See `mbfinotti/revops-skills@pipeline-stage-definition-audit` for the closed-won entry criteria this skill's gate builds on - stages are its output, this skill's input.
- See `mbfinotti/revops-skills@crm-data-governance` for who owns and maintains the fields the packet depends on once the process is live.
- See `mbfinotti/revops-skills@customer-health-score` for health scoring that starts from the packet this skill defines.
- See `mbfinotti/revops-skills@customer-churn-signals` for churn signals that emerge after the handoff - the first baseline is set from the packet this skill defines.
- See `mbfinotti/revops-skills@revenue-leakage` for quantifying what unmanaged handoff gaps cost - that skill finds the leak, this one closes it.
- See `mbfinotti/revops-skills@lead-routing` for assignment-rule patterns when picking the post-sale owner from a pool - the routing logic transfers directly.