SaaS onboarding that helps people get real work done

Imagine opening a new expense app because a colleague needs an expense approved. Your invitation leads to a company dashboard, a profile form, and a tour of reporting features. By the end, you know where the charts are. You still need to find the claim and work out what approving it will do.

That review is a useful place to start when designing SaaS onboarding. Build the first visit around work someone is ready to do, and the product team has a concrete way to evaluate the experience: can a new user finish the task, see the result, and understand what happens next? For the invited manager, that means making an informed decision and getting back to the rest of her day.

Let the invitation lead to the work

Consider a fictional company trying an expense tool across several offices. Alex has submitted a train receipt. His manager, Priya, needs to review the claim before finance can arrange reimbursement. They are entering the same product with different jobs to do.

For Priya, a useful first visit could begin at Alex's claim after sign-in and the necessary access checks. The receipt is there, the relevant policy is available, and the review action explains where the claim will go next. She can make an informed decision without first learning how to build a report or connect an accounting system.

That last distinction matters. Priya may have permission to review expenses but no authority to configure the company's integrations. Putting that setup in her welcome sequence creates a problem she cannot solve. It belongs with the administrator who can act on it.

Intercom's 2018 approach to value-based onboarding starts with the job a customer wants the product to do. Here, that means choosing a first task for each role. Alex needs to submit a valid claim to the right manager. Priya needs to record a review decision. Finance needs enough information to handle the next stage. A shared “onboarding complete” label would tell the team very little about which of those things happened.

Put the explanation beside the decision

As Priya reviews the receipt, she may need to understand why an expense category has been flagged. That is a good moment to offer a short explanation of the policy and a way to ask Alex for more information. A policy lesson shown at the beginning of the tour is harder to use once she has reached a particular claim.

The Nielsen Norman Group's discussion of tutorials and contextual help describes the interruption and memory problems of instructions presented outside the task. It also recognizes tutorials that let people practice and return to the guidance later. The question is whether the help is available when a person has a reason to use it.

Someone exploring the product before receiving a claim could try an optional sample. Keeping it clearly labeled and separate from live work lets them practice without notifying colleagues or moving a real expense forward. When they switch to an actual claim, show who will receive it and what their decision will do.

GitLab's first-commit tutorial follows that kind of learning: users change a file and verify the result. A practice expense could end with a recorded review and an updated status, giving the person something they have done and can inspect.

Make the handoff visible

Now suppose Alex submits his claim after Priya has finished work in another time zone. When he returns, he needs to know that it arrived and is waiting for her review. An incomplete onboarding indicator leaves several possibilities open: perhaps the upload failed, perhaps he missed a field, or perhaps he is simply waiting for someone else.

A useful status can answer those questions in place. Show the successful submission and the current reviewer. If the receipt is still processing, say so. If a missing permission is blocking access, explain who can resolve it. Keep Alex's work so that his next visit starts with the claim he already prepared.

The next morning, Priya opens the claim and asks which project the journey belongs to. She has completed a review action, even though the claim needs more information. Alex can now supply what is missing. A flow that counts only approvals as success would overlook that progress and could encourage a decision before the reviewer has enough context.

Once the claim is approved, its status should explain the next stage with finance. Approval and reimbursement are separate moments. Both matter to Alex, and the first-use experience should help him tell them apart.

Measure progress across the people involved

A tour-completion event can show whether people finished the introduction. To understand this workflow, the team also needs to follow submission, review access, and a recorded decision. Amplitude's documentation describes events and the properties that give them context; its funnel guidance makes clear that conversion depends on the events selected for the analysis.

In this example, connect the work through the claim and the organization, while keeping each person's role clear. Alex and Priya should not have to perform the same sequence for their progress to count. Keep practice claims distinguishable from live ones, and record the workflow without collecting receipt contents just to describe its status.

Look at preparation time and waiting time separately. A claim might be quick to submit and sit overnight because its reviewer is offline. The full elapsed time matters to the employee; time spent filling out the claim helps the team investigate the submission experience. Separating those times helps the team see whether Alex struggled to submit the claim or was simply waiting for Priya.

When comparing designs, use a consistent observation window and account for differences in roles, permissions, and available claims. If more users complete their first task, the team has a promising result to investigate. Whether that improvement leads to people staying with the product is a question to follow over time.

Start with one first visit

Choose one role and write down what a successful first visit would leave behind. For Priya, that might be a recorded decision on an eligible claim, with the next step clear to both her and Alex. Keep the outcome specific enough that someone watching the session could recognize it.

Then watch a new user try to reach it. Notice where they stop to interpret a label, look elsewhere for information, or encounter a requirement they cannot complete. Pick one obstacle, change that part of the experience, and observe another attempt. This gives a founder or product team a manageable improvement to test and a result they can inspect.

On Priya's next visit, the useful starting point is Alex's answer or the next claim waiting for review. Helping her reach that point gives the first visit a purpose she can carry into the second.