Onboarding Documentation Template

An empty state should answer three questions: What is this area for? Why is it empty? What should I do next? Keep it to 1-2 sentences plus a clear CTA button. Example: "No projects yet. Projects organize your team's work into trackable milestones. [Create your first project]." Avoid generic messages like "Nothing here yet" that provide no direction.

Both. Self-service onboarding (docs + in-app guidance) should work for 80% of users. Customer success-guided onboarding should be reserved for enterprise accounts where the contract value justifies the cost. Even guided onboarding should use the same documentation as self-service. The CS team walks through the same getting started guide with the customer. The [Stakeholder Management Handbook](/stakeholder-guide) covers building these cross-team handoff processes.

5-7 emails over the first 14 days is standard for SaaS products. The first email (welcome) should arrive immediately. Space subsequent emails 1-3 days apart. Stop sending onboarding emails once the user activates. Switch to feature education emails after activation. Never send an onboarding email and a marketing email on the same day.

Provide a working sample project, pre-populated test data, or a sandbox environment. Developers and technical users learn by exploring, not by reading. A getting started guide that says "clone this repo, run this command, see this result" converts better than any amount of conceptual explanation. See the [Getting Started Template](/templates/getting-started-template) for the step-by-step format.

When the activation rate plateaus despite product improvements, when a major UI redesign ships, or when the user persona shifts. Also rewrite if your support data shows that 20%+ of tickets come from onboarding issues. Minor updates (screenshot refresh, copy tweaks) should happen continuously. Full rewrites should happen 1-2 times per year. ---