Skip to content

SOP-095 — Learner onboarding program

Guide

<!-- last-reviewed: 2026-06-01 · owner: Customer Success (Customer Success Director) -->

SOP-095 — Learner onboarding program

SOP · owner: Customer Success (Customer Success Director). Layer: SOP/Runbook (docs/canon.md). The learning model lives in docs/concept.md; success terms in docs/glossary.md — not restated here. Pre-launch note: no learner, account system, or telemetry exists yet (ADR-0006; the channel is unlaunched). This authors the onboarding program stub-first against the concept; it activates at the Operate/Grow gate when real learners arrive. The unit boundaries are in ../units/customer-success/charter.md.

Interface Contract

  • Inputs: a learner handed off at sign-up / a partner cohort handed at agreement ← from Growth (Director) · trigger: (pending — sign-up handoff not wireable until accounts exist)
  • Inputs: registered-learner acquisition→retention seam ← from Growth Director · trigger: audience handed to retention
  • Inputs: onboarding-relevant research findings ← from <Design Research Director> · trigger: research findings issued
  • Outputs: learner health-score requirements (signals · thresholds · interventions) → to Data & Analytics Director · trigger: health-score requirements issued
  • Outputs: approved onboarding program (SOP / cohort doc) → to Archivist · trigger: artifact approved
  • Outputs: new CS term / canon-relevant change → to Documentarian · trigger: document changed
  • Outputs: onboarding SOP → to Quality & Risk Director · trigger: review requested
  • Handoff trigger (in): a learner reaches sign-up (handed from Growth), or a new learner segment / partner cohort needs an onboarding program designed
  • Handoff trigger (out): the onboarding program is approved (its activation checkpoint and exit criterion are falsifiable) and its health-score requirements are handed to Data & Analytics to instrument
  • Definition of Done before handoff:
    • [ ] Entry trigger named — the exact action/event that starts the sequence
    • [ ] Activation checkpoint is a single, observable, falsifiable action (NOT “logged in”; e.g. “completed first exercise and received feedback”) — derived from the concept’s CHECKS/outcome step (concept.md:102-104)
    • [ ] Each touchpoint carries medium · timing · owner (CS or Community Manager) · message intent · the signal that tells you it worked
    • [ ] Exit criterion named — the condition that moves a learner to steady-state engagement
    • [ ] Success is an outcome, not a vanity metric (logins/completions refused)
    • [ ] Health-score requirements (signals · healthy/at-risk/churned thresholds · intervention per threshold) drafted as requirements, not a schema (DA owns the schema)
    • [ ] No learner contact data in the program doc or any edge (PA-only)
    • [ ] Pre-launch status stated; no fabricated learners or activation figures
    • [ ] Learnings captured to docs/knowledge/ if any
    • [ ] Approved against the frozen exemplar; handed to the Archivist (0 drift)

Purpose

Produce a deliberate onboarding program — entry trigger → milestones → a falsifiable activation checkpoint → exit criterion — that takes a new learner (or partner cohort) from sign-up to first meaningful outcome, so “activated” means a demonstrated behavior change, not a login. Onboarding is a program with observable checkpoints, not a one-time email.

When to use

A learner reaches sign-up (handed from Growth), or a new learner segment / partner cohort needs an onboarding program designed or reviewed.

Flow

flowchart LR
  A["Understand context<br/>(concept · existing artifacts · research)"] --> B["Define success<br/>30 / 60 / 90 days"]
  B --> C["Name entry trigger"]
  C --> D["Define activation checkpoint<br/>(observable, falsifiable)"]
  D --> E["Design touchpoints<br/>(medium · timing · owner · intent · signal)"]
  E --> F["Name exit criterion"]
  F --> G["Draft health-score requirements<br/>→ Data &amp; Analytics"]
  G --> H["Approve · hand to Archivist"]
  classDef s fill:#1d4ed8,color:#fff,stroke:#1e3a8a
  class A,B,C,D,E,F,G,H s

Text fallback: understand the context (docs/concept.md, existing onboarding artifacts, Design Research findings) → define success at 30/60/90 days in two sentences → name the entry trigger → define the activation checkpoint as an observable, falsifiable action → design the touchpoints (each with medium, timing, owner, intent, success signal) → name the exit criterion → draft the health-score requirements for Data & Analytics → approve and hand to the Archivist.

Steps

  1. Understand the context. Read docs/concept.md for the learning model and target learner; Glob/Grep docs/, specs/, reports/ for existing onboarding/success artifacts; pull any Design Research findings (research findings issued). Do not design blind.
  2. Define success in two sentences. What does success look like for this segment at 30 / 60 / 90 days? If you cannot write it in two sentences, it is not ready — align with the Principal/CGEO first.
  3. Name the entry trigger. The exact action/event that starts the sequence (e.g. account created, first lesson requested).
  4. Define the activation checkpoint. A single observable, falsifiable action that marks the learner activated — built from the concept’s CHECKS/outcome step (concept.md:104). Never “logged in”; something like “completed first exercise and received feedback”.
  5. Design the touchpoints. For each: medium, timing, owner (CS or Community Manager), message intent, and the signal that tells you it worked. Relationship messaging is CS’s; brand voice/look is Creative’s (do not author brand assets).
  6. Name the exit criterion. The condition that moves a learner from active onboarding to steady-state engagement.
  7. Draft the health-score requirements. Signals (session frequency, exercise-completion rate, time-to-next-session…), healthy/at-risk/churned thresholds, and the intervention each threshold triggers — as a requirements doc for Data & Analytics (health-score requirements issued). Not a schema.
  8. Approve and hand off. Write the program at docs/sop/onboarding-<cohort>.md (or the cohort doc); hand to the Archivist (artifact approved); notify the Documentarian of any canon-relevant term (document changed); capture any learning.

Roles / approvers

Run by the Customer Success Director. Charter/manual approval routes to the CGEO; SOP approval is the Director’s own (owner’s Director per canon RACI — for a Lead, the cluster head). Data & Analytics instruments the health-score requirements; Design Research supplies onboarding-relevant findings; the Principal/CGEO aligns on the success definition.

Guardrails

  • Activation is falsifiable — an observable action, never “logged in” (anti-vanity).
  • Requirements, not schemas — DA owns the event schema and scoring; CS authoring a schema is a boundary defect.
  • No acquisition / channel work — that is Growth; the handoff is at sign-up.
  • No brand assets / visual identity — that is Creative; CS owns relationship messaging.
  • No personal data — learner contact data is PA-only; no CS edge carries it.
  • State the pre-launch status — stub-first; no fabricated learners or figures.
  • Do not restate docs/concept.md or docs/glossary.md — link to them.

Job aid: JA-095-onboarding-activation-checklist.md. See also: SOP-096 (learner health review) · docs/units/customer-success/charter.md · docs/units/data-analytics/charter.md (the requirements↔schema boundary).