Most SaaS onboarding documentation starts as a pile of answers to whatever the last three customers asked. It works until it doesn't: guides overlap, nobody knows which one to send first, and new customers get a link to a page written for a version of the product that no longer exists.
A customer onboarding guide template fixes that by giving every guide the same shape and putting the guides in a deliberate order. Below is the template we recommend, the first-week milestones it is built around, the five guides to write first, and the format that suits each stage.
Start from milestones, not features
Customers do not want to learn your product. They want to get to the point where it is useful to them. So before writing a single guide, list the milestones a new account must hit to get there.
For most B2B SaaS products, the first week looks something like the table below. Rename the milestones to fit your product, but keep them as outcomes the customer can verify, not tasks you would like them to do.
| When | Milestone | How the customer knows it worked | Guide that gets them there |
|---|---|---|---|
| Day 0 | Account is set up | They can log in and see their own workspace, not a demo | Account setup guide |
| Day 1 | First core action completed | They see the first real result (a report, a project, a published page) | First core action guide |
| Day 2–3 | Data or tools connected | Their real data shows up in the product | Key integration guide |
| Day 3–5 | Team invited | At least one colleague has logged in | Invite your team guide |
| Day 5–7 | Admin basics in place | Roles, billing, or settings match how they work | Admin configuration guide |
If you have usage data, use it to check these milestones against accounts that stayed. If you don't, start with your best guess and adjust once you see where new customers stall.
The onboarding guide template
Every onboarding guide should follow the same skeleton. Consistency matters more than polish: when customers have read one of your guides, they should know where to look in the next one.
- Title as an outcome. "Connect your CRM" beats "CRM integration settings". Start with a verb.
- Who it is for and how long it takes. One line, for example "Workspace admins, about 5 minutes".
- Before you start. Permissions, plan level, or information the reader needs to have ready (API key, CSV file, admin access).
- Steps. One action per step, with a screenshot or short clip showing exactly where to click. Name the button as it appears on screen.
- Check it worked. What the reader should see when they are done. This is the step most guides skip, and it is the one that stops support tickets.
- If something goes wrong. The two or three most common failure points and how to fix them.
- What next. A link to the next guide in the sequence, so onboarding feels like a path rather than a library.
Keep each guide to a single milestone. If a guide needs more than ten or twelve steps, it is usually two guides. Split it and link them with the "What next" section.
Which guides to write first
You do not need fifty guides on launch day. You need the five that cover the first week, written well. In order:
- Account setup. Signing in, creating the workspace, and the two or three settings that change everything downstream.
- First core action. The single task that delivers the product's value for the first time. This is your most important guide; give it the most care.
- Key integration. The connection most customers need before the product becomes part of their day. Pick the integration most of your accounts use, not every integration you support.
- Invite your team. Inviting, assigning roles, and what invitees see when they first log in.
- One admin task. Billing, permissions, or whichever admin setting causes the most questions in your first month of support.
A good way to find the content for these guides: look at your setup calls. If your team walks every new customer through the same sequence on a call, that sequence is the guide. Record it once and turn it into documentation instead of repeating it live.
After the first five, add guides in order of how often a question comes up in support or onboarding calls. Feature-adoption guides for secondary features come last.
Pick the right format for each stage
Different onboarding moments call for different formats. A customer deciding whether to bother needs something quick to watch. A customer configuring SSO needs exact, scannable steps they can follow at their own pace.
| Stage | What the customer needs | Best format |
|---|---|---|
| Welcome / orientation | A quick sense of how the product fits together | Short walkthrough video (1–3 minutes) |
| Setup and configuration | Exact steps they can follow at their own pace | Written step-by-step guide with screenshots |
| First real task | Help at the moment they are doing it | Live in-app walkthrough or embedded guide |
| Team rollout | Something admins can forward to colleagues | Shareable guide link or help center collection |
| Ongoing reference | One place to look things up later | Branded help center |
The catch is maintenance. If the video, the written guide, and the in-app walkthrough are built separately, they drift apart with every release. This is the problem Steperly is built for: you record the workflow once, Steperly drafts the guide steps with AI, and the same guide can be shared as a written guide, a narrated walkthrough video, a help center entry, or a live in-app walkthrough.
Where onboarding guides should live
A great guide nobody can find does nothing. Put onboarding guides in at least three places:
- The welcome email sequence. One guide per email, matched to the milestone the customer should hit that day.
- Inside the product. Link or embed the relevant guide on the screen where the task happens, especially empty states.
- A help center collection. Group the first-week guides as a "Getting started" collection, in milestone order. A branded portal keeps this looking like part of your product rather than a separate site.
Customer success teams should also send guides directly. When a customer asks a setup question, the reply should be a link to the guide, not a fresh explanation. If no guide exists, that question goes to the top of your writing list.
Keep the guides accurate after launch
Onboarding guides go stale faster than any other documentation, because onboarding screens change often. A few habits keep them honest:
- Add "check onboarding guides" to the release checklist for any change that touches signup, setup, or settings screens.
- Assign an owner per guide. Unowned guides are the ones that rot.
- Look at which guides people actually open. Guide analytics in Steperly show engagement with published guides and portals, which tells you what to update first and what to retire.
- Re-record rather than patch. If a flow changed substantially, recording it again is usually faster than editing old screenshots one by one.
For products with frequent UI changes, Steperly's drift detection flags live walkthrough targets that may no longer match the product, so you can fix them before customers hit a broken step.
A one-page checklist
Before you call your onboarding guides done, run through this list:
- Every first-week milestone has exactly one guide.
- Every guide follows the template: outcome title, audience and time, prerequisites, steps, check, troubleshooting, next.
- Each step has a visual showing exactly where to click.
- Guides are linked in order, so the last line of one leads to the next.
- The "Getting started" collection is linked from the welcome email and the product.
- Each guide has an owner and is on the release checklist.
That is a complete first version. It will not cover every question, but it will cover the path most customers take, which is what onboarding is for. If you already record walkthroughs on Loom or Zoom, see how to turn a screen recording into a step-by-step guide for the fastest way to convert them.