Onboard a Customer to First Value

{"category":"operations","description":"Use when a customer success or implementation owner is responsible for moving a newly signed customer from sales context to a verified first useful business outcome. The unit of work ends at observable first value, rather than completion of setup checkboxes. Do not use for a mature customer optimization campaign or a custom product build.","inputSchema":{"additionalProperties":false,"properties":{"contractAndSalesRefs":{"description":"Relevant agreement, sales discovery, promised outcomes and kickoff information.","items":{"type":"string"},"type":"array"},"customer":{"description":"Customer account identifier.","minLength":1,"type":"string"},"targetFirstValue":{"description":"The first business outcome the customer should achieve.","minLength":1,"type":"string"},"timeConstraints":{"description":"Target dates, customer availability or deployment limitations.","items":{"type":"string"},"type":"array"}},"required":["customer","targetFirstValue"],"type":"object"},"schemaVersion":1,"steps":[{"expectedOutputs":[{"description":"Customer outcome, success signal, in-scope use case and promise gaps.","kind":"first-value-definition"}],"id":"TT7T","instructions":"Read sales notes, agreed scope, relevant contract constraints, stakeholders and known risks. Confirm what was actually promised and which value event the customer can realistically observe soon. Make the event specific: actor, workflow, successful result, observable evidence, and what does not count. Separate activation/setup from useful impact. Surface contradictions between the sales story and delivery capacity before asking the customer to commit. Gate: first value is measurable, authorized and achievable without unspoken dependencies.\n\nV2 practical protocol:\nFirst-value contract: define a real actor and workflow, start trigger, successful business result, evidence source, customer verifier and exclusions. Example: \"An operations analyst independently completes the first monthly reconciliation using production-like authorized data, with results approved by the process owner,\" not \"account provisioned.\" Set Time Zero explicitly (e.g. signed kickoff acceptance, not whichever timestamp makes TTV appear smaller) and define whether clocks pause for customer-caused or vendor-caused blockers. Capture baseline and target only if agreed. Separate product activation, first usage, first successful task, and realized value.","resourceHints":[],"title":"Audit the promise and choose a first-value outcome"},{"expectedOutputs":[{"description":"Milestone plan, prerequisites, risks and accountabilities.","kind":"onboarding-plan"}],"id":"WT1E","instructions":"Map the critical path from current state to first value: accounts, permissions, data, integration, security reviews, configuration, customer action and training. Assign responsibility by role without inventing individuals. Estimate dates with confidence and identify blocked work and a parallel quick-win route if possible. Avoid broad implementation plans that obscure the next customer-visible milestone. Gate: each prerequisite has an owner or a clear decision request, and the next usable action is visible.\n\nV2 practical protocol:\nBuild a dependency register with prerequisite, evidence of completion, owner role, lead time, critical path relation, blockage risk and contingency. Calculate forecast TTV from the longest dependent chain or a transparent milestone range, not by summing all parallel task durations. Tag customer-controlled approvals versus vendor-controlled work. Use low/most-likely/high timing where estimates are uncertain and replan when prerequisites slip. Design the minimum customer-visible route to the first value event; defer noncritical training and configuration until after validation.","resourceHints":[],"title":"Build a minimal onboarding plan around dependencies"},{"expectedOutputs":[{"description":"Kickoff decisions and verified configuration/activation status.","kind":"activation-evidence"}],"id":"WXVZ","instructions":"Present the intended business outcome, success event, scope, timeline, roles and customer responsibilities. Capture explicit agreement on prerequisites and decision ownership. Guide or perform configuration within granted permissions; document what was changed, in which environment, and what remains unverified. Avoid requesting sensitive credentials in conversation or using live data without approval. Gate: the first workflow is configured or blocked for an identified reason, and participants know the evidence needed to claim success.\n\nV2 practical protocol:\nConfiguration acceptance: for each required environment, access and integration, specify expected state, verification method, evidence, permission owner and rollback/undo path for consequential changes. Distinguish \"provisioned\", \"configured\", \"tested\", and \"approved\". Kickoff decisions must confirm first-value event, critical customer actions and who can approve production use. Do not request credentials or perform changes requiring new permissions without consent. The setup section should be proportional: a light SaaS onboarding should not inherit an enterprise integration checklist.","resourceHints":[],"title":"Run kickoff and configure the first workflow"},{"expectedOutputs":[{"description":"User enablement kit and real-workflow observations.","kind":"usage-validation"}],"id":"4JW4","instructions":"Create only the necessary enablement material for the initial user group: a short task-based walkthrough, exception handling and where to get help. Observe users attempting their real job, not just completing a demo. Collect task success, time to result, support friction and reasons for abandonment where visible. Distinguish training attendance from competence. Gate: the evidence supports or refutes that users can complete the target workflow without extraordinary assistance.\n\nV2 practical protocol:\nUser-observation script: give the user a real task with realistic input, ask them to attempt it independently, note success/abandonment, time-to-complete, errors, support needed and subjective perceived value. Record sample size and participant role. Training attendance and account login do not count as task success. If the workflow cannot be safely trialed, label the observation a simulation and require appropriate later evidence. Capture the top blocker with reproducible steps rather than a generic \"more enablement needed.\"","resourceHints":[],"title":"Enable the actual users and observe real usage"},{"expectedOutputs":[{"description":"Verified value event or explicit gap and corrective plan.","kind":"first-value-review"}],"id":"KEAP","instructions":"Check the agreed value event against real customer evidence. If not achieved, classify the obstacle, choose a bounded correction and retest; do not mark onboarding successful because milestones were ticked. Confirm the customer's perception of value and distinguish observed benefit from estimated ROI. Capture the minimal reusable operating notes required for the customer to continue, without adding an unnecessary generic handoff phase. Gate: first value is verified or the precise blocker and recovery test are documented.\n\nV2 practical protocol:\nTTV measurement: TTV = timestamp of first verified value event − defined Time Zero. Report calendar days (and business days only if their calendar is defined), any agreed clock exclusions, and evidence/corroborating user. Compare outcome to target and previous cohort only when definitions match. If value is not reached, classify obstacle as access/data/integration, user workflow, adoption, scope/value mismatch or customer approval, then choose one limited corrective experiment with threshold and next review date. Do not mark \"first value achieved\" from activation alone.","resourceHints":[],"title":"Verify first value and resolve material gaps"}],"title":"Onboard a Customer to First Value"}