gaintrace Onboarding Plan — built backwards from time-to-value
You are the onboarding lead for a new customer, and the plan you write is judged on whether the customer renewed, not on whether it executed tidily. The first renewal is won or lost here — in months two to four of the first term, while the project still looks healthy and long before anyone opens a renewal plan [C23]. A rookie plan runs forwards: kickoff to go-live, marked complete — and a meaningful share of those accounts do not renew, because go-live completes our task list, not theirs.
Lincoln Murphy names the failure precisely: the Success Gap is "the gap that exists between your customer functionally completing the tasks necessary in your product to be 'successful' from your point of view as the vendor and them actually achieving their Desired Outcome" (Sixteen Ventures) [P]. The elite version inverts the arithmetic: fix the value gate — the date by which the activation event must be observed, at the right frequency, by the right people, against a captured baseline — lay every phase backwards from it, check whether the plan fits in the time remaining, and say so on day one if it does not.
The second job is stall detection. TTFV overrun, milestone slippage, services burn and a dark environment all fire during implementation and predict the first renewal 180–365 days out [P] — that is the Failed launch pattern in churn-risk, and it fires from this skill's Step 7 signals rather than from renewal-window analysis. The failure is never detection difficulty; it is that nobody instrumented the project, so the stall surfaces at the first business review instead of in week three.
Read ../cs-context/references/evidence-standard.md first. Onboarding data is the sparsest in CS — no usage baseline, no history, no trend — so UNKNOWN — requires X discipline matters more here than anywhere else in the library.
Before Starting
Read
.agents/cs-context.md. If absent, runcs-contextfirst. Four fields make this skill work: the activation event, the target TTFV in days, the notice period and the segment boundaries. Check the business model against../cs-context/references/business-model-profiles.md— a consumption or PLG account has no seat rollout and no admin-certification gate, so Steps 6–8 change shape for it.Every missing input resolves read it · ask it · mark it — never guessed. Read it if it is in the data, in
cs-context, or derivable. Ask it if two likely answers produce materially different work. Otherwise writeUNKNOWN — requires <source>and cap confidence. Protocol:../cs-context/references/clarification-protocol.md.Ask these four, tappably, in one batch. Use
AskUserQuestion: 2–4 mutually exclusive options each, the recommended one first and labelled(Recommended), a one-line description under each saying what it changes, all four in one ask — never drip-fed. Drop any questioncs-contextor the request already answers; if that leaves none, ask nothing.
| Header | Question | Options — recommended first, each with what it changes |
|---|---|---|
Scope |
What am I planning? | This new signing (Recommended) — full backwards plan, Steps 1–10 · In-flight audit — stall read, float and the re-baseline decision on one live implementation · Recovery — a gate missed or float negative; exec-sponsored re-plan with the commercial conversation named · Portfolio — every pre-value-gate account, ranked stall queue first, Plan Cards only for the fired ones |
Gate |
What is the activation event for this account? (skip if cs-context §5 has it) |
Use the one in cs-context §5 (Recommended) — the standard gate; V-day computes and every phase lays backwards from it · An account-specific one I'll name — this customer's own success criterion overrides the default and moves V-day · Not defined — nothing dated is produced; the run derives a candidate gate (references/phase-playbook.md §7) and returns that instead of a plan |
Touch |
How is this implementation staffed? | Score it from complexity (Recommended) — integration count, migration and business units decide; ARR breaks ties · White-glove, already SOW'd — named PM and architect; longest phase durations, weekly steering · Guided or tech-touch — CSM-led or in-product; shorter phases, and stalls trigger automation rather than meetings |
Audience |
Who reads the output? | Me, working (Recommended) — the full internal plan · Weekly implementation review — plan plus the ranked stall queue · Plan plus the customer drafts — adds the send-ready kickoff agenda and MAP in §12 |
Never block. If nothing comes back, run on the recommended defaults, state them in one line
above the Bottom Line, and record every one in the Assumptions table. Never ask what
cs-context already holds — ARR, segment, renewal date, notice period, fiscal year, source
inventory. A missing notice period is a finding: it goes to the register and turns every gate into a floor.
Take whatever data the user has — CSV, TSV, XLSX, JSON, NDJSON, warehouse query results, an exported project plan, a pasted kickoff transcript, a screenshot described in prose, or no file at all, in which case the answers above are the input and the plan says so. Run
../cs-context/scripts/ingest.pyfirst on any supplied file. It sniffs encoding and delimiter, finds the real header row under an export's title rows, maps columns onto the canonical schema with a confidence per column, normalises dates, money and booleans, resolves accounts across files and reports the join rate.- Confirm every column mapping below 0.80 confidence before using those numbers — and
contract_start,renewal_dateandnotice_period_daysat any confidence, because a wrong mapping there moves V-day and silently moves every phase behind it. - Degrade, never refuse. Partial data gives a partial plan with a coverage figure and a capped confidence, not an error. Under 40% coverage, name the gap instead of scoring.
- Never assume the export is complete or current. Ask its as-of date, print it in the header table, and treat any milestone export older than the last project write as unverified.
- Confirm every column mapping below 0.80 confidence before using those numbers — and
Detect data state. Run the freshness and coverage checks in
../cs-context/references/evidence-standard.md§7 across the seven families. Onboarding accounts fail the usage check for a legitimate reason — they are not live yet — so distinguish not-measured from measured-and-empty:NULLis a data gap, but0core actions on day 70 of a live environment is the most important finding you will produce (normalized-schema.md§1).Suppress the standard health model. Trend scoring without a baseline produces garbage. GitLab's public production config NULLs every health measure except CSM sentiment for the first 30 days of onboarding "due to insufficient stats and inaccurate results"
[V]. Where your CS platform supports lifecycle-phase scoring, give implementation its own model rather than reusing the steady-state one. Score onboarding on the gates and the ten Step 7 signals, never on decay.
How This Skill Works
| Mode | When | Produces |
|---|---|---|
| Plan | New signing, no plan exists | Backwards-planned phase schedule, both gates, stall instrumentation, MAP |
| Audit | Implementation in flight | Stall read against every signal, float remaining, re-baseline or confirm |
| Recovery | A gate missed, or float is negative | Re-baselined plan, exec-sponsored, with the commercial conversation named |
| Handover repair | Sales handover was thin, wrong, or absent | Sold-vs-Real reconciliation and the recovered field set |
| Portfolio | All accounts pre-value-gate | Ranked stall queue by stalled ARR × days past target |
Run sequence: anchor the value gate → reconcile sold-vs-real → pick the mode → backwards-plan the ten phases → forward-feasibility check → define both gates → open the first-renewal risk record at V-day → instrument stall detection → design enablement → schedule the handover → set the scoreboard. The rule that makes it work: plan backwards, execute forwards, and never let the two meet without a float number.
Brief is the default output. Twenty lines or fewer: both gate dates, the float number and band, the decision-window verdict, the one decision needed this week with its owner and date, confidence in three words, and one line naming what would change the call. Emit the full Output Template only when the user asks for it, when it goes into a steering review or a QBR, or when the Failed-launch compound matched. Brief drops the display of the reasoning, never the reasoning — provenance on every number, UNKNOWN — requires X where data is missing, and the confidence word earned by coverage. Close it with one line: Full plan, coverage ledger and workings on request.
**Northwind — V-day 29 Oct, G-day 30 Aug. Float 3 days: NO ABSORPTION.**
Decision window (months 2–4) closes 29 Oct; V-day lands on it to the day, so one slipped close
cycle moves the first renewal from decided-on-evidence to decided-on-faith. Migration is the
whole critical path and has one owner [project tracker · phases 2–4 · through 2026-08-27].
**Do:** Priya asks Dana Osei for a second migration owner by 4 Sept, or we cut scope to the
single close use case. Confidence: medium (5/7 families). What would change it: a second named
customer owner, which restores 8 days of float.
*Full plan, coverage ledger and workings on request.*
Step 1 — Anchor the value gate
Do this before writing a single task. Every other date in the plan is derived from it.
opt_out_deadline = renewal_date − notice_period_days
evidence_window = days to accumulate value evidence and hold one business review before the
customer decides. Enterprise 90 · Mid-market 60 · Tech-touch 30 [P]
VALUE GATE (V-day) = min( opt_out_deadline − evidence_window ,
contract_start + target_ttfv_days ) (target from cs-context §5)
value_lag = days from production go-live to the activation event occurring at its
natural cadence. Enterprise 21 · Mid-market 14 · Tech-touch 7 [P]
GO-LIVE (G-day) = V-day − value_lag
DECISION WINDOW = contract_start + 30d → contract_start + 120d (months 2–4) [P]
VERDICT = V-day ≤ decision_window_close → "decided on evidence"
V-day > decision_window_close → "decided on faith"
RISK RECORD OPENS = the V-day event date — activation attested, or V-day passed unattested.
Never G-day. Never the project-completion date.
R1 — the opt-out calendar. Use the opt-out deadline, never the renewal date: a 90-day notice period on a 1 Feb renewal means the decision lands in October, so a plan targeting February targets a date that has already passed. The evidence window is why the notice period belongs in an onboarding plan at all — value must exist and be evidenced before the decision, not before the invoice. And value_lag is not padding: one occurrence of the activation event is a smoke test, while value is the event recurring at the cadence the business case assumed — at least two natural cycles (a monthly close needs 60+ days, not 21). Print both dates first.
The decision window is the second computed date nobody prints. The customer forms their renewal view in months two to four of the first term — whether the product works in their environment, whether their own people changed how they work, whether the signer can describe a result to someone who did not sign. By month five those are answers, and the renewal conversation reports them rather than changing them. So compute the window, compare V-day to its close, and print the verdict in the Bottom Line. Decided on faith is not a warning label; it is a structural fact about the plan you just wrote, and it obliges one of three named choices on day one — cut scope to a smaller first use case, move the gate by renegotiating the term, or accept a first renewal argued without evidence, with an owner and a date on whichever you pick. Derivation and the worked example: references/first-renewal.md §2.
Step 2 — Reconcile what was sold against what exists
The handover is where onboarding plans acquire their fatal assumptions. Walk references/handover.md in full — 24 transfer fields, six mismatch classes, and a detection test for each inside the first ten business days. The non-negotiable output is the Sold-vs-Real table: for every claim in the business case, state what exists. Six gap classes, each with a different recovery — capability (promised, not shipped) · scope (services undersized) · timeline (a go-live date nobody costed) · stakeholder (nobody who will use it was in the cycle) · commercial (entitlement far above deployable capacity) · data (the source data does not exist in the shape required).
A capability gap found in week 2 is a roadmap conversation — held under R19, no date you do not own — while the same gap in month 5 is a renewal negotiation, and that difference is the entire return on this step. If the handover is thin or absent, run Handover repair first — a plan built on a guessed use case hits every milestone and misses the outcome.
Step 3 — Choose the onboarding mode
Segment does not decide this alone. Murphy's point stands: there is "no such thing as a 'high-touch' or 'tech-touch' customer" — only customers for whom a given experience is appropriate [P]. Score complexity first; let ARR break ties.
| Mode | Fits when | Vendor staffing | Cadence | Plan artifact |
|---|---|---|---|---|
| White-glove | ≥2 integrations, migration required, >1 business unit, or regulated | Named PM + solution architect + CSM, SOW-backed | Weekly steering + daily standup during migration | Full MAP, both sides, dated |
| Guided | 1 integration, no migration, single business unit | CSM-led, pooled architect hours | Weekly 30-minute working session | Short MAP, 8–12 rows |
| Tech-touch | No integration, self-service config, admin = user | In-product flow + cohort webinars + pooled inbox | Automated, triggered on milestone stall | In-product milestone checklist |
| Recovery | A gate missed, or float is negative | Exec sponsor both sides, PM re-assigned | Twice-weekly, exec-visible | Re-baselined MAP with a stated cause |
What changes between modes is not meeting frequency — it is who defines the success criteria, who executes the migration, how enablement is delivered, and how a stall escalates. The full mode-by-dimension matrix is references/phase-playbook.md §2; apply it before committing to a date. Never assign white-glove to an account whose ARR cannot carry it — over-servicing is a margin decision wearing a service costume, and the arithmetic is references/stall-detection.md §4.
Step 4 — Backwards-plan the ten phases
Lay the phases back from V-day, not forward from kickoff. Objective, both-side owners, duration by mode, dependencies, exit criteria and skip-risk for each: references/phase-playbook.md.
| # | Phase | Ends when (exit criterion, abbreviated) | Risk if skipped |
|---|---|---|---|
| 0 | Pre-kickoff | Handover reconciled, admin named, access requested, agenda sent | Kickoff becomes discovery; two weeks lost |
| 1 | Kickoff | Success criteria, stakeholders, timeline, escalation path and the customer's internal comms plan are written down and confirmed | No shared definition of done; every later disagreement is unresolvable |
| 2 | Configuration | Contracted primary use case configured in a non-production environment | Product configured to the vendor's demo, not the customer's process |
| 3 | Integration | Each contracted integration authenticated, syncing, and error-free for 5 consecutive days | Silent value killer — the account looks live and produces nothing |
| 4 | Data migration | Record counts reconciled to source within tolerance, signed off by a named customer owner | Users hit wrong data on day one and never return |
| 5 | Admin enablement | ≥2 customer admins can complete the 6 core admin tasks unaided | Single-admin dependency; every request becomes a support ticket |
| 6 | End-user enablement | ≥N users per team completed training and performed the core action once | Licences provisioned, nobody trained, utilisation flatlines |
| 7 | First value (V-day) | Activation event observed at cadence, by the buying team, against the captured baseline, attested by the customer — and the first-renewal risk record opens here | The Success Gap — the project closes, the value never arrives, and nothing opens a record until T-90 |
| 8 | Usage expansion | Second team or second use case live; breadth ≥ the core-feature floor | Single-use-case dependency; one process change ends the account |
| 9 | Steady-state handover | Owning CSM briefed, 30/60/90 booked, baseline and evidence transferred | The receiving CSM restarts discovery; the customer repeats themselves |
Parallelism is the whole schedule. Configuration, integration and migration run concurrently only if the customer has a separate owner for each; a single-admin customer serialises all three, typically triples the critical path, and carries the R5 single-thread tax from day one. Emilia D'Anzica's minimum-contact-count gate on marking onboarding complete [P] should gate the start too — name the owners before promising the date, and state the critical path and the parallelism assumption.
Step 5 — Forward-feasibility check
Run the plan forwards from today and compare:
critical_path_days = Σ remaining durations of phases on the critical path
FLOAT = V-day − (today + critical_path_days) (business days)
| Float | Read | Required action |
|---|---|---|
| ≥ 20 days | Healthy | Proceed; re-check float weekly |
| 5–19 days | Tight | Remove one non-critical phase from the path, or add a customer owner. Name which |
| 0–4 days | No absorption | Any single slip breaks it. Escalate to the exec sponsor now, naming the dependency you need unblocked |
| Negative | The plan does not fit | Say so in the first five lines. Choose explicitly: cut scope to a smaller first use case, move the gate by renegotiating the term, or accept a first renewal decided without value evidence. Never quietly re-baseline |
Negative float on day one is the most valuable thing this skill produces, and the thing a forward-planned task list structurally cannot see. In week one it is a scope conversation; in month four it is a save play. scripts/onboarding_plan.py computes both gates, the decision window, the backwards schedule, the float and all ten signals.
Step 6 — Write both gates, separately
Different gates, different owners, different evidence. Conflating them is why implementations "delivered on time" churn at the first renewal.
| Go-live gate (G-day) | Value gate (V-day) | |
|---|---|---|
| Question it answers | Is the product in production doing the contracted job? | Has the customer got the outcome they bought? |
| Owner | Vendor implementation lead | Customer's named business owner |
| Evidence | Environment = production · integrations green 5 days · migration reconciled · ≥2 admins certified · ≥N users trained | Activation event at cadence for ≥2 cycles · performed by the buying team, not just the admin · measured against the kickoff baseline · a named customer owner attests in writing |
| What it must never be | A date in a project plan | A vendor's opinion that things look good |
The baseline rule. Capture at signature or kickoff, never at renewal — a baseline taken after go-live is not a baseline. Minimum record: value_driver, metric_name, baseline_value, baseline_period, baseline_source, measurement_owner_customer, target_value, target_date, attribution_pct (set by the customer, not by you). Without it V-day is unprovable and the first renewal is argued on feelings. Schema: references/kickoff.md §5.
The account's risk record opens at V-day, never at go-live. Go-live and first value are different events with different owners, different evidence and different dates, and conflating them is precisely why implementations "delivered on time" churn at the first renewal. G-day closes our task list. V-day closes the onboarding, and it is the only event that opens the first-renewal risk record. Three opening states, no fourth: VALUED · LIVE, NOT VALUED · NOT LIVE.
| Rule | Enforcement |
|---|---|
opened_at is the V-day event date — activation attested, or V-day passed unattested |
An artifact whose opened_at equals G-day, the last completed milestone or a project-completion percentage is invalid output. Re-date it, or fix the plan that made them coincide |
Onboarding is complete only where the record opens VALUED |
G-day evidence complete and V-day unattested is LIVE, NOT VALUED — the account stays with the onboarding lead, the gate is re-dated once in writing with the cause named, and §10 handover is not emitted |
| The record is opened once and carried, never re-opened at T-90 | renewal-prep and qbr-builder read it. A renewal plan that starts a fresh record has discarded the two quarters of evidence that explain the outcome |
No expansion ask until the record reads VALUED (R8 — and R9's 3× rule is unevaluable without value evidence) |
State that it was withheld and why. Never omit it silently |
| Moving V-day is a decision, not an edit | Owner, date and stated cause, written into the record (R14). A quiet re-baseline manufactures first-renewal churn by removing the one date that would have exposed it |
Required fields, the three states in full and the refusal list: references/first-renewal.md §3–4 — read it before opening any record.
Step 7 — Instrument stall detection
Every signal below is instrumented at kickoff and evaluated weekly. Thresholds, false-positive traps and escalation ladders: references/stall-detection.md. This is the summary every plan carries:
| # | Signal | Computation | Fire threshold | Escalation |
|---|---|---|---|---|
| S1 | Milestone slippage | % milestones overdue, cumulative_slip_days |
≥2 overdue or cumulative slip >30d [P] |
Re-plan with the customer, in writing, within 5 business days |
| S2 | TTFV overrun | actual_elapsed / target_ttfv_days |
>1.5× → risk; >2.0× → severe; no value event by day 90 → severe [P] |
Severe: exec-sponsored recovery, re-baselined go-live |
| S3 | Blocked-task ownership | Share of overdue tasks whose owner is customer-side | ≥60% customer-side for 2 consecutive weeks | Escalate to the exec sponsor with the named blocker, not to the admin |
| S4 | Unresponsive admin | Days since last bilateral touch (exclude one-way vendor outbound) | 2 missed cadence periods: white-glove 10 business days, guided 10, tech-touch 21 [P] |
Multithread — go to the sponsor and to a second named contact the same week |
| S5 | Environment never in production | prod_events / total_events |
<0.20 after day 90 post-go-live [P] |
Technical escalation; treat as go-live not achieved regardless of project status |
| S6 | Dark account | Zero qualifying core events since contract_start |
>60 days from contract start [P], strength: near-certain |
Same-week exec-to-exec; this is the highest-precision signal in the set |
| S7 | No new users provisioned | new_users_L30 vs the rollout plan |
Zero new users in 30 days while seat_utilisation < 0.85 |
Rollout is stalled at the pilot; name the blocking team and its lead |
| S8 | Services burn ratio | hours_burned / hours_sold; scope_change_count |
>1.3× sold hours, or ≥2 change orders [P] |
Read it with S2 — see the pairing rule below |
| S9 | Use case never live | Has the account ever performed the sold use case's core action? | Never, by day 90 post-go-live [P], strength: near-certain |
Re-open the Sold-vs-Real table; this is usually a gap you already logged |
| S10 | Kickoff-to-config stall | config_complete_date − kickoff_date vs the mode default |
>2× the mode default | The configuration is blocked on a decision nobody has been asked to make |
Burn-ratio pairing rule — the commonest misread in onboarding analytics is treating high burn as risk when on a complex deployment it is investment. Read S8 only against S2/S6; the four-cell read is references/stall-detection.md §4, and scripts/onboarding_plan.py prints it. Separate vendor-side slip from customer-side slip — in the data they are identical, a milestone past its due date, and they are opposite problems with opposite plays. Tag every task with the side that owns it; that tag alone says whether to add vendor resource or escalate to the sponsor (§5 of the reference).
S2 + S1 + S8 + S6 co-occurring is the Failed launch compound — P0, lead time 180–365 days, predicting the first renewal specifically. It is churn-risk's pattern, and it fires from these signals rather than from renewal-window analysis: S2→U9 · S1→U10 · S8→U11 · S6→Z4. When it matches, write the handoff payload into the risk record (references/first-renewal.md §5), hand the four values to churn-risk with the lead time and the opt-out decision date named, withhold the renewal motion and the expansion ask (R8) with the reason stated rather than omitted, and run an exec-sponsored recovery with a re-baselined go-live — consider a term restart, not a renewal ask. The other four compounds, reported matched and not-matched, are references/stall-detection.md §6.
Step 8 — Design enablement so it can be measured
Training that cannot be measured did not happen. Split it — the two audiences fail differently.
Detail in references/phase-playbook.md §5–6.
| Admin enablement | End-user enablement | |
|---|---|---|
| Audience · format | 2+ named admins (never 1) · live + sandbox exercise + certification | Every provisioned seat, by team · train-the-trainer or per-team session |
| Success measure | Both admins complete the 6 core admin tasks unaided, observed | ≥70% of provisioned seats performed the core action ≥1× within 14 days of training [P] |
| Failure signature · re-run trigger | Every config change arrives as a support ticket · any admin change (U15) |
Seats provisioned, licence utilisation flat · any team below 40% activation 30d post-training |
Target a curated core-feature set, not the catalogue — Pendo's 2019 Feature Adoption Report (615 subscriptions, three-month window) found ~80% of features rarely or never used and ~12% driving ~80% of daily usage [M]. Name the 5–8 value-path features with product, freeze the list, measure against it. And the customer's internal comms plan is a deliverable here, not a courtesy (five fields: references/kickoff.md §7) — an unannounced rollout produces trained users who were never given permission to change how they work.
Step 9 — Hand over to steady state
Onboarding closes at V-day, never at G-day — the handover starts from the opened risk record (Step 6), and a handover section with no record above it has been scheduled rather than performed. What transfers, in the account record and not in a person's head: the first-renewal risk record · the captured baseline and its measurement owner · the attested V-day evidence · the Sold-vs-Real table with open gaps and dates · the stakeholder map with the champion's own words on why they bought · the configuration decisions and why · open defects with committed dates · the deferred-scope list · the next expansion milestone · the opt-out deadline.
| Checkpoint | Held by | Purpose | Exit criterion |
|---|---|---|---|
| Day 30 post-V | Onboarding lead + receiving CSM + customer admin | Confirm the activation event still occurs at cadence and the admin has not gone quiet | Core-action volume ≥ the V-day rate; no U8 regression |
| Day 60 | Receiving CSM + champion | Second team or use case in motion; value quantified against baseline | A written value statement with a number and a customer-set attribution % |
| Day 90 | Receiving CSM + exec sponsor | First business review; re-baseline objectives for the remaining term | Success plan for the rest of term, dated, both sides carrying items |
If V-day passed but the day-30 check fails, that is U8 activation regression — an onboarding failure
arriving late. Return the account to the onboarding lead rather than opening a save play.
Everything that leaves the building goes through ../cs-context/references/customer-voice.md first — R18, the firewall, is absolute here.
Warmth is specificity, not adjectives — name their number, their words, the thing their team did; if a sentence could go to any of forty customers, rewrite it. Banned outright: "just checking in", "touching base", "circling back", "hope you're well", "as per my last email", "reaching out", "we value your partnership", "let me know your thoughts", "at your earliest convenience", "drive adoption", "leverage".
The disclosure firewall is absolute: the float number, either gate as a gate, the mode name, stall signal names, "stalled" or "at risk", burn ratio and services hours, any ARR figure, the opt-out deadline, coverage tier, champion-departure inferences, competitor intelligence and any assessment of a named person never reach the customer in any wording. Internal says float is 4 days; the customer note says this sequence has no slack after 3 October.
Step 10 — Set the scoreboard
Report per account and per cohort. Definitions, cohort-construction rules and the reading rules: references/stall-detection.md §7 and ../cs-context/references/metric-dictionary.md. The eight that must appear: TTFV (contract start → first completed customer-defined success milestone) · TTV / time-to-live (→ production go-live) · onboarding cycle time, decomposed into its four segments · milestone adherence with cumulative slip · services burn ratio, read only against activation · activation rate by 30/60/90-day cohort · stalled-onboarding ARR, the number that buys onboarding headcount · share of first-term accounts whose V-day falls after the months 2–4 decision window closes, which is the leading indicator of next year's first-renewal churn. The gap between TTV and TTFV is the Success Gap, in days.
Two integrity rules: benchmark against your own cohort baseline, not a published TTV median — the cross-company figures circulating online are content-marketing numbers with no disclosed method — and never report a mean, because onboarding durations have a long right tail and the mean hides exactly the accounts that will not renew. Median and P90, with the n.
Output Template
Use verbatim. For portfolio scope, emit a ranked queue first, then a Plan Card per account with a fired stall signal. State any default the run leaned on in one line above the Bottom Line.
# Onboarding Plan — <Account> · <mode> · <date>
**Internal.** The customer-facing MAP is a separate artifact — see assets/mutual-action-plan.md.
## Bottom Line
<3 sentences: the value gate date, the float, and the single decision needed this week with its owner.>
| | |
|---|---|
| ARR / term / start · first renewal | $X · <annual/multi-year> · <date> · renews <date>, notice <N>d, **opt-out deadline <date>** |
| **Value gate (V-day)** | <date> — <derived from opt-out−evidence window / contract start+target TTFV> |
| **Go-live gate (G-day)** | <date> — V-day − <value_lag>d |
| Activation event · Float | <the named event, from cs-context §5> · <N> business days — <Healthy / Tight / No absorption / NEGATIVE> |
| **Decision window (months 2–4)** | <contract_start+30d> → <contract_start+120d> · V-day falls <inside / after> it → **<decided on evidence / decided on faith>** |
| **First-renewal risk record** | opens <V-day> · state <VALUED / LIVE, NOT VALUED / NOT LIVE / not yet reached> · owner <name> · decision date <opt-out deadline> |
| Mode | White-glove / Guided / Tech-touch / Recovery — <the complexity reason> |
| Stall signals fired | <n of 10> — <names> |
| Confidence | High/Medium/Low — <criteria met> |
## 1. Anchor arithmetic
| Input | Value | Source |
|---|---|---|
| renewal_date · notice_period_days · **opt_out_deadline** | | CRM / contract · computed |
| evidence_window (mode default) · target_ttfv_days · contract_start | | [P] · cs-context §5 · CRM |
| **V-day = min(opt_out − evidence, contract_start + target_ttfv)** | | computed |
| value_lag · **G-day = V-day − value_lag** | | [P] · computed |
| **decision_window** = contract_start +30d → +120d · V-day vs its close | | [P] · computed |
## 2. Sold vs Real
| Sold | Evidence it was sold | What exists today | Gap class | Owner | Resolution | By |
|---|---|---|---|---|---|---|
Missing handover fields: <list, each as `UNKNOWN — requires X`>
## 3. Stakeholders
| Name | Title | Side | Role (economic_buyer/champion/admin/power_user/…) | Owns which phase | Backup named? |
|---|---|---|---|---|---|
**Minimum-contacts gate:** <n> named customer owners across <n> phases — <met / NOT met>. **Handover completeness: <n> of 24.**
## 4. Phase plan (backwards from V-day)
| # | Phase | Start | End | Days | Vendor owner | Customer owner | Depends on | Exit criterion | Parallel? |
|---|---|---|---|---|---|---|---|---|---|
**Critical path:** <phases> = <N> days. **Parallelism assumed:** <which, and why it holds>
## 5. Feasibility
| Remaining critical path | Projected V-day | Planned V-day | **Float** | If negative, the choice being made |
|---|---|---|---|---|
| <N> business days | <date> | <date> | **<N>d — <band>** | <cut scope / move the gate / accept an unevidenced first renewal> — owner, by date |
## 6. The two gates
| Gate | Date | Evidence required | Owner | Status |
|---|---|---|---|---|
| Go-live (G-day) | | | Vendor implementation lead | |
| **Value (V-day)** | | | <named customer business owner> | |
### Baseline captured at kickoff
| value_driver | metric_name | baseline_value | baseline_period | baseline_source | measurement_owner_customer | target_value | target_date | attribution_pct |
|---|---|---|---|---|---|---|---|---|
## 6b. First-renewal risk record — opens at V-day, never at G-day
Emit this section **before §7 and before §10**. §10 is not emitted while it is unpopulated. Every empty cell is written `UNKNOWN — requires <source>`; no row is dropped.
| Field | Value |
|---|---|
| `opened_at` — the V-day event date (attested, or passed unattested). **Never G-day** | |
| `opening_state` — `VALUED` / `LIVE, NOT VALUED` / `NOT LIVE` / not yet reached | |
| `record_owner` — named person, never a team | |
| `first_renewal_decision_date` — opt-out deadline (R1), never the renewal date | |
| `decision_window` — contract_start +30d → +120d · V-day inside it? · verdict | |
| `value_evidence` — event · cycles · performed by whom · vs which baseline · attested by whom · date | |
| `baseline_ref` · `open_gaps` — Sold-vs-Real rows still open, with dates | |
| `signals_at_close` — the §7 set as it stood at V-day, carried not recomputed | |
| `handoff_to` — `churn-risk` always; `save-play` where Failed launch matched · date | |
**Failed-launch handoff** — emit only where the compound matched: S2 <value> · S1 <value> · S8 <value> · S6 <value> → U9 · U10 · U11 · Z4 · lead time 180–365d to <opt-out deadline> · account state <NOT LIVE / LIVE, NOT VALUED> · **withheld:** renewal motion, expansion ask (R8), for the reason stated.
## 7. Stall instrumentation
| # | Signal | Current value | Threshold | Status | Evidence | Escalation if fired |
|---|---|---|---|---|---|---|
<all ten signals, always — including the ones checked and clear>
**Compound check:** Failed launch (S2+S1+S8+S6) — <matched / not matched>. <Implication.>
**Blocked-task ownership split:** vendor-side <n> · customer-side <n> · shared <n>.
## 8. Enablement
| Track | Audience | Format | Date | Owner | Success measure | Measured on |
|---|---|---|---|---|---|---|
**Core-feature set (frozen):** <5–8 named value-path features>
**Customer internal comms:** sender · date · distribution · stated deadline · non-adoption consequence
## 9. Actions this week
| # | Action | Owner | By | Expected effect | Success measure |
|---|---|---|---|---|---|
## 10. Steady-state handover
| Checkpoint | Date | Held by | Purpose | Exit criterion |
|---|---|---|---|---|
| Day 30 / 60 / 90 post-V | | | | |
**Transfers to the receiving CSM:** <the §6b risk record · baseline · value evidence · Sold-vs-Real open gaps · stakeholder map · configuration rationale · open defects · deferred scope · next expansion milestone · opt-out deadline>
**Risk record handed to:** <named person> on <date> — §6b `opening_state` = <state>. Onboarding is closed only where that state is `VALUED`.
## 11. What would change this plan
<2–3 specific, observable events that would move V-day, the mode, or the float band.>
### Assumptions
| # | Assumption | Why it was needed | If wrong |
|---|---|---|---|
<one row per default this run leaned on, each with a concrete consequence — "may affect results" is not a consequence>
### Coverage Ledger
| Signal family | Source checked | Status | Notes |
|---|---|---|---|
| Product usage & adoption | | | Environment state, provisioning, core actions, prod/sandbox split |
| Commercial & contract | | | Sold-vs-Real, entitlement, opt-out deadline, SOW hours |
| Relationship & engagement | | | Admin responsiveness, sponsor, multithreading, kickoff attendance |
| Support & reliability | | | Implementation tickets, blocking defects, integration errors |
| Sentiment & VoC | | | Kickoff sentiment, post-onboarding CES, champion's own words |
| Billing & payment | | | First invoice status, services invoicing, PO/procurement blocks |
| Firmographic & external | | | Customer reorg, layoffs, acquisition, competing internal project |
**Coverage: X / 7 (Y%) → confidence capped at <level> (R23).** Blind spots: <which families are missing and what they hide during onboarding.>
When the audience answer asked for them, §12 closes the artifact — the only part that leaves the building. Templates: assets/kickoff-agenda.md · assets/mutual-action-plan.md. One fence per artifact, each with its own label, leak scan run on every one.
## 12. Customer-facing drafts
════════════════════════════════════════════════════════════
CUSTOMER-FACING — copy the block below and send as written.
Everything above this line is internal. Do not forward it.
════════════════════════════════════════════════════════════
**<Kickoff agenda / MAP / re-plan note> — to <named recipient>, send by <date>**
```text
<Send-ready. Plain text for an email client: blank line between paragraphs, • bullets, no
markdown headings, no pipe tables, no ** bold. Opens on something only this account could
produce — their number, their words, the outcome they named. One dated ask. Every slot
filled: a fence containing [Name] or <date> is not send-ready, so delete the sentence that
needed the missing value and raise it above the divider as UNKNOWN — requires X.>
```
Quality Bar
- V-day is computed from the opt-out deadline and the TTFV target, and the arithmetic is shown
- G-day and V-day appear as separate gates with different owners and different evidence
- C23 — §6b is present and populated,
opened_atis the V-day event date and never G-day, a project-completion date or the last milestone;opening_state,record_ownerandfirst_renewal_decision_date
…(truncated)