Product tour examples: 8 patterns and what each one gets right

Most product tours fail the same way: eight steps on the first screen, each one naming a button the user can already see. The tours that work are narrower. Each one does a single job, at a moment when the user actually needs it.

Below are eight patterns that keep coming up in SaaS products. For each one: when it fits, how many steps it needs, sample copy you can adapt, what to measure, and how to build it. We make Clew, so the build notes use it, but every pattern works in any tour tool or in your own code. In Clew, tours and tooltips are on the Free plan; modals, audience rules and checklists start on Pro.

For the same thing measured instead of described, see our teardowns of real products: one product per piece, the exact path, the number of steps and the time to the first useful action.

The eight patterns at a glance

• 1. Welcome tour to the first key action: 3–5 steps, new users, first session.
• 2. Feature announcement: a modal plus 1–2 steps, existing users.
• 3. Empty-state nudge: 1 step, on a screen with nothing on it yet.
• 4. Checklist-driven activation: 3–5 items, the first days.
• 5. Contextual tooltip on first use: 1 step, on a hard control.
• 6. “What moved” tour after a redesign: 2–3 steps, existing users of that screen.
• 7. Upgrade prompt at the limit: 1 modal, users who hit a plan limit.
• 8. Second-visit tip: 1–2 steps, returning users.

1. Welcome tour to the first key action

The classic product tour, and the one most often done badly. A good welcome tour does not show the interface. It walks to one action, the one after which the product starts being useful: creating the first project, connecting a data source, inviting a teammate.

• When: the first session of a new user, on the main screen.
• Steps: 3 to 5. If you need more, the path is too long for a tour. Split it and move the rest to a checklist (pattern 4).
• Copy: “Start here: create your first project. It takes a minute and everything else hangs off it.” Then “Name it after a real client, so you can see how reports will look.” Then “Invite the person you work with. Projects are more useful with two.”
• Measure: completion rate (reached the last step ÷ saw step 1), drop-off per step, and, in your own analytics, how many users who finished the tour did the key action within a day.
• Build it in Clew: format “Step-by-step tooltips”, page rule on your dashboard URL, audience rule on a property such as signedUpDaysAgo equal to 0 passed with identify(), frequency “Once per visitor”.

Every step should point at the element the user has to press, and every step should say why, not what. “This is the Projects button” is wasted on someone who can read. “Projects keep each client’s reports apart” is not.

2. Feature announcement

You shipped something that existing users will not discover on their own. An email gets opened days later, out of context. An in-app announcement shows up on the screen where the feature lives, at the moment the user is there.

• When: the first visits after a release, for users who were already active before it.
• Steps: a modal with one sentence and one button, optionally followed by one tooltip on the new control. Two screens at most.
• Copy: modal title “Reports now export to Google Sheets”, text “One click, and the sheet stays in sync when numbers change.” Button “Show me”. The tooltip on the export button: “Here. Pick a sheet or create one.”
• Measure: how many people who saw the modal pressed “Show me” rather than closing it, and, in your analytics, usage of the feature among those who saw the announcement against those who did not.
• Build it in Clew: a “Modal window” on the page where the feature lives, with an audience rule so new sign-ups (who get the welcome tour) don’t see it too. Frequency “Once per visitor”. A modal and a tour are separate items and only one of them is on screen at a time, so it won’t stack on top of another tour. That also means the modal can’t hand over to a tooltip: either say where the control is in the modal’s text, or make the announcement a short tour whose first step points at the new control.

Put the announcement where the feature is, not on the dashboard. A modal on the dashboard about a feature three screens away asks the user to remember it until they get there.

3. Empty-state nudge

The empty screen is where many new users stall: a list with nothing in it and a toolbar full of options. A single tooltip on the primary action of that screen often does more than a whole tour, because it arrives exactly when the user is looking at nothing.

• When: a screen that is empty until the user creates something: no contacts, no tasks, no reports.
• Steps: 1.
• Copy: “No contacts yet. Import them from a CSV, or add the first one by hand. You can clean them up later.”
• Measure: views and dismissals of the hint, and, in your analytics, how many users go from the empty state to a first item.
• Build it in Clew: “Step-by-step tooltips” with one step anchored to the button and an exact page rule on that screen’s URL. To show it only while the screen is really empty, pass a count from your app, such as identify({ contactsCount: 0 }), and add an audience rule on it. Frequency “Once per visitor”.

The best fix for an empty state is in the product itself: sample data, a template, an import button that stands out. The tooltip is the quick version you can ship today while the real fix waits for a sprint.

4. Checklist-driven activation

Some products need several actions before they are useful: connect an integration, import data, invite the team, set up a notification. A tour can’t hold that, because the user will leave in the middle and come back tomorrow. A checklist can: it stays in a corner, remembers progress between visits and shows how much is left.

• When: the first days after sign-up, when activation takes more than one action.
• Items: 3 to 5, in the order that brings value fastest. The first item should be the easiest, so the bar moves on day one.
• Copy: title “Get your workspace ready”, items “Connect your calendar”, “Import contacts”, “Invite a teammate”, “Send your first campaign”.
• Measure: how many users complete each item and the whole list, and how long it takes. The item where most people stop is the one to rework first.
• Build it in Clew: format “Onboarding checklist”. On Business, items tick themselves when the user reaches a page, clicks an element, or when your code calls Clew.complete('invited') after the real event. That beats asking the user to tick a box. A tour and a checklist can be on screen together.

More on checklist items and their order: onboarding checklist with examples.

5. Contextual tooltip on first use

Some controls are hard: a date-range picker with relative dates, a permissions matrix, a field that expects a regular expression. Explaining them in the welcome tour is too early, because the user hasn’t met them yet. A hint that appears when the user reaches the control is on time.

• When: the first time a user reaches a control that generates support tickets.
• Steps: 1, sometimes 2.
• Copy: “Relative dates move with time: “last 30 days” in a saved report always means the 30 days before today.”
• Measure: views of the hint and, outside Clew, support tickets about that control before and after.
• Build it in Clew: “Step-by-step tooltips” with one step and the trigger set to hover or to a click on the control. A hover hint appears after the pointer rests on the element for 400 ms; keyboard users get it on focus, touch users on the first tap.

6. “What moved” tour after a redesign

After a redesign, the people who get lost are not new users but your most loyal ones. Their muscle memory is now wrong. A two- or three-step tour on the changed screen, shown only to people who used the old one, saves a wave of “where did X go?” tickets.

• When: the first visits to a redesigned screen, for users who signed up before the change.
• Steps: 2 or 3, one per thing that moved.
• Copy: “Filters moved here, above the table, so they stay visible while you scroll.” Then “Export is now in this menu, together with Share.”
• Measure: completion, and support tickets that mention the moved controls in the week after release.
• Build it in Clew: a page rule on the changed screen and an audience rule on a property your app passes, for example signedUpBefore2026_09 set to true. Take it down after a few weeks: the tour is about the change, not the screen.

7. Upgrade prompt at the limit

A user who hits a plan limit is at the most natural moment for an upgrade conversation: they want to do something and can’t. A prompt at that moment, that says what the limit is and what the next plan gives, converts better than a banner that is always there. It also annoys people less.

• When: the user has reached a limit: projects, seats, exports.
• Steps: 1 modal.
• Copy: title “You’ve used all 3 projects on Free”, text “Pro gives you 20, plus shared reports. Your current projects stay as they are.” Buttons “See plans” and “Not now”.
• Measure: clicks on “See plans” ÷ views, then upgrades in your billing data. Keep an eye on dismissals: a prompt shown too often trains people to close it unread.
• Build it in Clew: a “Modal window” with an audience rule on a property such as projectsLeft equal to 0, which your app passes with identify(). Rules are checked again when identify() runs and nothing else is on screen, so the modal can appear right after the limit is hit, without a page reload. Clew shows the prompt. Enforcing the limit is still your app’s job.

8. Second-visit tip

Not everything belongs in the first session. Keyboard shortcuts, saved views, bulk actions: these matter once the user is past the basics. A single tip on the second or third visit teaches one power feature at a time, when the user has room for it.

• When: the 2nd to 5th visit, one tip per visit at most.
• Steps: 1 or 2.
• Copy: “Tip: press / to search everything from anywhere.”
• Measure: views and, in your analytics, adoption of the feature among users who saw the tip.
• Build it in Clew: “Step-by-step tooltips” with the trigger “on the Nth visit”. A visit here is a page load with the widget in that browser, not a session, so set N higher than you would for sessions.

What all good tours have in common

• One job each. A tour that welcomes, announces and upsells at once does none of it.
• Anchored to what the user must press. A step that points at decoration is a slide, not a tour.
• Shown on a trigger, not on every page load. The URL, the audience and the moment matter more than the copy.
• Easy to leave. Every step can be closed. A closed tour is an answer (“not now”), not a failure to fix by showing it again.
• Measured per step. Completion alone hides where people leave. Drop-off per step shows which screen or sentence loses them.
• Maintained. A front-end release can remove the element a step points at. Anchor steps to stable attributes like data-tour="new-project" and check for broken steps after each release.

Test the pattern, not just the copy

Once a tour has traffic, an A/B test tells you more than any list of examples. Split visitors between two versions of the same tour: fewer steps against more, a checklist starting with a different item. Keep the one that gets finished more often. Clew runs A/B tests on Pro and up: it checks significance and lets you make B the main version in one click. The A/B testing guide walks through a test end to end.