Most onboarding checklists assume you have product analytics and thousands of sign-ups. You look at the funnel, find the step where people drop, and fix it.
Many small B2B SaaS teams have neither. The founder creates accounts, sends access and explains the product on a call. There is no dashboard to look at, and the numbers are too small to mean much anyway.
This is the checklist I use in that situation. It comes from two paid reviews this year: a customer-journey review of a B2B messaging product in July, and an onboarding and activation audit of a founder-led B2B SaaS in September.
Before the checklist: what does a ready account look like?
I separate two things. The first is the account state: the data and decisions a customer needs before useful work can start. The second is the work itself, which the customer does again and again.
I write down a candidate “ready” state early, as a hypothesis.
For example: data imported, one key record marked, no duplicates waiting for review, one event planned. I do not turn it into a customer checklist. First the team has to check it against who keeps using the product and who pays.
1. Collect what already exists
Before I open the product, I ask for what the team already has: customer questions, walkthrough videos, call recordings, support emails. I map each question to a screen.
In one audit, all eleven customer questions started with “How do I…”. Not one said that something was broken. Most of the features they asked about already existed; people did not find them.
Questions show where to look. They do not show everything that breaks. The clearest defect I found in that audit was one no customer had described.
2. Walk the product as a new user, with messy data, on every device
I sign up as a new customer and use my own test data, not a clean demo account. Real files have duplicates, name variants and half-filled fields, so mine do too.
I test on every device the job uses. If customers set up on the web and then work on a tablet, I test both.
For the July review I used three personas, each with one variable that changed. One of them never opens a laptop, so her whole journey happened on a phone. That showed where the mobile experience got worse.
3. Does the first screen name a task or a control?
An empty screen tells a new user what to do first. In one product, the empty list pointed to a “+” button. The upload was available, but the screen did not present it as the starting task. My recommendation was a primary “Upload a list” action that opens the existing flow, with manual entry as a second option. I check whether the first screen names the job the customer came to do, in their words.
4. Does every action end with a clear and true result?
After each action I ask two questions: “Does the user see what happened?” and “Does what they see match what was saved?”
In a controlled import, the product found possible duplicates, but the main screen on a tablet gave no signal that review work was waiting. Finding duplicates and telling the user about them are two different jobs.
I also follow the result one step further: after navigation, after a reload, in the next workflow. An import can report success and still lose part of the file’s structure. A cleared field can still keep its old value behind the scenes.
5. Test working state in bad conditions
Real work does not always happen on good Wi-Fi, so I test the moments when the connection fails.
In one test I kept the iPad connected to Wi-Fi but removed internet access. Two populated panels in a comparison view went empty. The saved data was still there when each team was opened separately. So this was a display failure, not data loss, and the write-up said exactly that.
6. Put guidance where the task happens, not at first login
In the September audit, the same person did two kinds of work, sometimes months apart. A tour at first login cannot help with a task they first need months later.
So I check where help appears. Is it at the moment of the task? If an action matters for something later, does the product say so at that moment, or only at the end? And what does a second user see when they join an account that is already set up? Help triggered by an empty screen never reaches them.
7. Write each finding so the team can act on it, and label every claim
I write each finding in the form the team will use:
- defect: steps to reproduce, actual result, expected result;
- copy change: current wording and proposed wording;
- behaviour change: a user story with Given/When/Then acceptance criteria.
Each claim also gets a label: I observed it, the client told me, I inferred it, or it still needs testing. Before the report goes out, I re-check. In September I withdrew one finding after a second check on iPad contradicted it.
8. Measure without analytics
Without analytics, the first measurement plan uses what the team already stores: database fields and a small manual log. I keep “never started” separate from “started and got stuck”, and I record who did the first real task and with what help. I wrote more about this in The founder is inside your funnel. The full method, with a minimum set of fields, is in How to measure user activation without product analytics.
With small numbers I report counts, not percentages. “3 of 8 accounts” says more than “37.5%”.
What an audit like this cannot tell you
An audit shows where the product does not guide the user and what breaks. Without usage data or interviews with customers, it cannot tell you how many people hit each problem, or which one costs the most. I write this limit into the report, so nobody reads the priority list as a measured result.
The checklist on one screen
| N | What I check | Signal of a problem |
|---|---|---|
| 0 | What does a ready account look like? | Nobody can say what has to be true before useful work starts |
| 1 | What customers already ask | Questions start with “How do I…” for features that exist |
| 2 | The product as a new user, with messy data, on every device | The flow only works with clean demo data or on one device |
| 3 | The first screen | It points to a control (“+”), not to a task |
| 4 | The result of each action | The product finds something but does not tell the user; the screen and the saved state disagree |
| 5 | Bad conditions | Content disappears when the connection fails |
| 6 | Where guidance appears | Help only at first login; a new user in a set-up account gets no help |
| 7 | How findings are written and labelled | Opinions without steps, or claims without evidence |
| 8 | Measurement without analytics | “Did not complete setup” hides several different states |
FAQ
My fixed-scope audit of one onboarding flow takes 5 business days after I receive the requirements: a short written description and product access.
Yes, with limits. You can find where the product does not guide the user and what breaks. You cannot say how many users hit each problem.
A UX audit finds interface problems. An onboarding audit, as I do it, diagnoses product logic — whether the flow asks users to act before they trust the product enough to do so. The fix is usually a flow change, not a UI change.
Treat it as a hypothesis. Check it against who converts or keeps using the product. With small numbers, report counts, not percentages.
If you want this done for your product, I run it as a fixed-scope Onboarding & Activation Audit: one onboarding flow, 5 business days.
Related: Onboarding and activation audit for a founder-led B2B SaaS · SaaS customer-journey review
