Onboarding checklist template · 5 min read
User Onboarding Checklist Template for SaaS Activation
A useful onboarding checklist is built backwards from one activation event: the action that shows a new user got value. Define that event first, list only the tasks that lead to it, give each task a completion rule tied to a real product action, and design the empty screens a new user lands on. The templates below cover each part.
The tasks are placeholders for a typical B2B SaaS product with workspaces and teammates. Replace them with your own product's steps. This is a method, not a measured result, so check any change against your own activation data.
Define the activation event first
Write the activation event as one sentence someone else could turn into a query. Every checklist task should help a user get there.
ACTIVATION EVENT DEFINITION: [Product name]
Unit: [user | account or workspace]
Event: [the value action, e.g. "creates and shares a first report"]
Threshold: [at least once | N times]
Window: within [N] days of [signup | workspace creation]
Source: [event name in your analytics, e.g. report_shared]
Excludes: [internal users, test accounts, actions on sample data]
Sentence:
"A [unit] is activated when it [event] [threshold] within [N] days of [start]."
Activation rate = activated [units] in the signup cohort
/ all [units] in that cohort x 100| Check | Passes when | Fails when |
|---|---|---|
| Tied to value | The action delivers the outcome the user signed up for | It's a setup step, such as completing a profile |
| Observable | One tracked event or stored record proves it happened | It depends on a survey answer or a guess |
| Reachable early | A motivated new user can do it in the first session or first few days | It needs weeks of data or a purchase first |
| Linked to retention | In your own data, users who reach it are retained more often than users who don't | Nobody has compared retained and churned users |
| Stable | The definition stays fixed long enough to compare cohorts | It changes every sprint |
The copyable onboarding checklist
There are two lists here: the steps your team follows to build onboarding, and the checklist your users see. Keep the user-facing list short, and give each item a completion rule based on a real product action, not a click on the checklist.
Build steps for your team
- Write the activation event. Use the definition template above and agree on it with product, growth and engineering.
- Map the shortest path. List the fewest actions a new user must take to reach the event. Anything not on that path can wait for later onboarding.
- Choose three to five tasks. Take them from the shortest path. Put a quick, low-effort task first so progress starts straight away.
- Write a completion rule per task. Name the event or stored record that marks each task done, and whether it belongs to the user or the workspace.
- Design the empty states. Every screen a task sends the user to needs an empty state that points at the next action. Use the empty-state checklist below.
- Decide skip and dismiss behaviour. Store skipped and completed separately, and let users hide the checklist without losing progress.
- Instrument and review. Track task completion and the activation event separately, and review both for each signup cohort.
USER-FACING ONBOARDING CHECKLIST: [Product name]
Title: Get [outcome] in [n] steps
Progress: [x] of [n] done
[ ] 1. [Quick first task, e.g. "Name your workspace"]
Done when: [workspace name is saved]
[ ] 2. [Connect or import, e.g. "Connect your data source"]
Done when: [integration status is connected]
[ ] 3. [Create the first core object, e.g. "Create your first report"]
Done when: [a report record exists]
[ ] 4. [Collaborate, e.g. "Invite a teammate"]
Done when: [a valid invitation is created]
[ ] 5. [The activation action, e.g. "Share your report"]
Done when: [the activation event fires]
On completion: [message naming the outcome] + [next suggested action]
On dismiss: [where the user can reopen the checklist]| Field | What to record |
|---|---|
| Task ID | A stable identifier that doesn't change when you rename the task |
| Owner | User or workspace, so a teammate's action updates the right checklist |
| Completion event | The event or record that proves the task is done |
| State | Not started, completed or skipped |
| Checklist version | So you can compare cohorts after you change the list |
Empty-state checklist
A new user's first screens are usually empty. Check each one against this list before launch.
- Says in one sentence what the screen will show once there's data
- Has one primary action, and it's the next step toward the activation event
- Offers sample data or a starter template where a blank start is hard
- Links to help for that specific screen, not the documentation home page
- Shows no charts, counters or tables that would only display zeros
- Still makes sense to a teammate who joins an existing workspace
- Has copy for its loading and error variants, not only the empty one
- Gives way to the real content as soon as the user creates the first item, without a page reload
How to do it with PLG OS
These are the parts of the checklist that PLG OS components cover, as described on plgos.com.
Build onboarding flows per user type
The onboarding page describes creating different onboarding flows to offer personalised experiences, with fully customisable components. PLG OS onboarding
Show a checklist with progress
The component library includes a Get Started Guide and a Quest List, and the Tutorial component page describes tracking tutorial progress with check marks. Tutorial component
Point users at the next task
Walkthroughs and Embedded Onboarding Tips are listed in the SDK component library for guiding users in context. SDK components
Record task completion and activation
PLG OS plans list custom events and attributes, and the onboarding page describes user analytics that map user interactions, so both can be recorded as events. PLG OS pricing
Hear where new users get stuck
Help Hub answers user questions inside the product, and the feedback and surveys components let users report friction as it happens. User assistance
Common questions
How many items should an onboarding checklist have?
Usually three to five. Fewer than three rarely leads anywhere, and a long list looks like work. If you need more, separate setup tasks from value tasks or move some to a later checklist.
Should an item be marked done when the user clicks it?
No. Mark it done when the product action it describes has happened, such as a record being created. A click on the item only shows the user opened it.
What's the difference between checklist completion and activation?
Checklist completion tells you whether users finished your list. Activation tells you whether they reached value. Track both: if completion rises but activation doesn't, the tasks are the wrong ones.
Should checklist progress belong to the user or the workspace?
It depends on the task. Personal tasks such as setting a profile belong to the user. Shared setup such as connecting an integration usually belongs to the workspace, so every teammate sees it done.
Should users be able to dismiss the checklist?
Yes. Let them hide it and reopen it later, and store skipped tasks separately from completed ones so your reports don't count a dismissal as success.
Basis and scope
This template is a drafting aid built on commonly used definitions and illustrative placeholders. It is not a measured benchmark or a customer case study. Prepared with AI assistance. Check product-specific behaviour against current documentation and your own data.