A live guide can start in two places. It can greet a new visitor on their first visit, or it can wait until a customer clicks a help link and asks for it. Both are useful. The mistake is to use the same guide for both moments.
This post is about timing and triggers: when a guide should start, and what the customer has just done when it does. For what to put inside a guide, see our posts on the live guided tour.
Two moments a customer needs a guide: the first visit, and the moment they get stuck
The first visit is when a customer knows least. They have just signed in, they do not know where anything is, and they are looking for a reason to keep going. A short first-run tour helps them find their feet.
The second moment comes later. The customer has used your product for a while, and now they need to do one specific thing they have not done before, such as exporting a report or changing a billing detail. They are not lost in general. They need one answer, quickly.
These two moments need different guides. A first-run tour that runs every time someone opens a settings page will annoy people. A help-on-demand guide that only appears after a click will be missed by people who have never seen the product before. Decide which moment each script serves before you record or build anything.
What a first-run tour should cover: one goal, three to five steps, a clear finish
A first-run tour has one job: get a new customer to their first useful action. Choose that action first. It might be creating a project, inviting a colleague, or adding the first record.
Keep the tour to three to five steps. Each step should point at one thing on the screen and say what to do with it. When the customer reaches the last step, the tour should finish with a clear statement that they are done, and tell them where to go next.
A clear finish matters more than most teams expect. If the tour simply stops, the customer is not sure whether they missed something. Ending with a short line such as "You have created your first project. Your next step is adding a team member" tells them the tour is over and what comes next.
When you write the script for a first-run tour, read each line aloud and ask whether a new customer would understand it without any background. If a step needs prior knowledge, it belongs in help on demand instead.
What help on demand looks like: short guides a customer chooses to start from a help link
Help on demand is a guide the customer starts themselves. It sits behind a help link, a button labelled "Show me how", or a link in a help article. The customer chooses it, so it can be a little longer and more specific than a first-run tour, but it should still be short.
Aim for one task per guide. "Change the email address on your account" is a good guide. "Everything about your account settings" is not. Customers arrive with a question, so the guide should answer that question and then stop.
Because the customer asked for help, start the guide from the place they are already looking. If the help link sits on the billing page, the guide should begin on the billing page, not on the dashboard. This small detail stops the customer from having to hunt for the screen you are describing.
How to decide which of your scripts belongs in which moment, with a simple checklist
Use this checklist for each script you plan to write:
- Is this the first thing a new customer needs? If yes, it is a first-run candidate.
- Does it take three to five steps or fewer? If it takes more, split it into separate guides.
- Does the customer need to have done something before this? If yes, it is help on demand, started after that earlier step.
- Would a returning customer want it? If they would, keep it as help on demand so it does not interrupt them.
- Does it touch something risky, such as a payment or a deletion? Think carefully about whether a guide should lead the customer there at all. Make sure the script tells them what they are doing and why.
- Can you name the page where it starts? If you cannot, the trigger is not clear enough yet.
If a script fails the first question but passes the others, it belongs in help on demand. Most products end up with one or two first-run tours and a larger set of help-on-demand guides.
Adding the guide with one script tag, or the browser extension on sites you cannot change
There are two ways to add the live guide to your product. If you can edit your site, add one script tag to the pages where guides should be available. Put it where your team can find and update it, so it is clear which pages carry it.
If you cannot change the site, for example because it is run by another team or a third-party platform, you can use the browser extension on the sites you need. This works for the customer's browser session on those pages, so check that the guide starts from the same screens you planned for.
Whichever method you use, test both moments. Sign in as a brand-new user and check the first-run tour. Then sign in as an existing user, open the help link and check the on-demand guide. Testing both on the same device is a quick way to find a trigger that fires too often or not at all.
Reusing the same script so the live guide, video and help article stay in step
A first-run tour and a help-on-demand guide often cover the same task. Rather than write each one twice, write the steps once and use them for the live guide, the narrated video and the step-by-step help article.
One script gives you all three outputs. The live guide shows the steps on screen, the video narrates them, and the help article lists them with screenshots. When you change a step in the script, the three outputs change with it, so customers see the same wording wherever they meet the task.
This matters most for first-run tours. A new customer may watch the video, follow the live guide, then look at the help article later. If the three disagree, they lose trust in all of them. Keeping one script as the source avoids that.
You can see how this works on the HandHoldly how it works page.
How nightly re-checks name the step that has stopped working, so you can fix it before customers meet it
Products change. A button moves, a label is renamed, a menu is reorganised. A guide that worked last week may now point at the wrong place.
HandHoldly re-checks your scripts every night. If a step no longer works, it flags that step, fires your webhooks, and emails the owners with the name of the step that has broken. You hear about the problem from the check, before most customers reach that screen.
With AI switched on, the tool can look for a button that has moved or been renamed and suggest a fix. The suggestion is a draft for you to check. You decide whether it is right, and you can save it into the script with one click. The re-check flags a broken step. It does not repair it on its own.
For first-run tours, this is especially useful. A broken first step is the first thing a new customer sees, so it is worth knowing about as soon as it happens. For help on demand, the check tells you which guide to update before a customer clicks a help link and finds it out of date.