Is your onboarding a documented, repeatable process, or does it live in your head? Show me the runbook.?

The full executive answer

Both exist, and the more important one is the product itself. The most failure-prone parts of onboarding are not documented as runbooks — they are engineered as code, which is stronger. The sample-data seeder is idempotent and only writes when an organisation has no real data, so it is safe and non-destructive by construction rather than by checklist. The guided tour, the journey rail and the diagnostic sequence the first weeks automatically. A new customer's path does not depend on me remembering steps.

Around that, the repo carries operational runbooks — internationalisation rollout is a documented runbook, for example — and the operational surfaces the runbooks reference are all live: status page, SLA page, changelog, trust pages. My white-glove layer for early customers — executive kick-off, first war-game, QBR cadence — is currently founder-delivered against a working checklist, and turning that checklist into the formal customer-success playbook is explicit roadmap work as the CS function is hired.

I would offer this test: put one of your teams through the trial with zero contact with me, and judge whether they reach a completed diagnostic unaided. Onboarding that survives founder absence is the standard we built to, because as you rightly imply, founder-dependent onboarding does not scale — and neither of us should want it.