What a live guided tour is, in plain English
A live guided tour sits inside your web app. When someone is using the product, the tour points at a real button or field, shows a short message beside it, and waits for them to act before moving on. The person is doing the task themselves, with a guide alongside them.
That makes it different from the other two kinds of help. A narrated video shows someone else using the product, and people usually watch it before they start. A help article is text and screenshots that someone reads when they are stuck. A live tour happens on the screen they are already looking at, at the moment they need it.
It is worth keeping all three in mind, because the same walkthrough can feed each of them. HandHoldly takes one script and produces a narrated video, a live guide inside the app and a step-by-step help article from it, so the three stay in step with each other.
Choose the moments that matter
A tour should not try to explain everything. Pick a small number of moments where a short prompt genuinely helps. Three moments cover most products:
- First visit. Someone has just signed in or arrived for the first time. A brief orientation, such as where the main menu is and what the first task is, is usually enough.
- First task. The moment someone tries the core action for the first time, such as creating a record, sending an invoice or uploading a file.
- The usual sticking point. Look at your support tickets and session recordings. Where do people hesitate, go back or ask for help? That is where a tour earns its place.
For each moment, write down what the person is trying to do and what they will see on the screen. If you cannot name the goal in one line, the moment is probably too broad. Split it or drop it.
Resist the urge to add a tour to every screen. Each extra prompt is one more thing to keep correct when the product changes, and a tour that appears everywhere quickly becomes something people click past.
Keep each step to one action and one sentence
Each step in a live tour should ask for one thing. Click this button. Type your company name here. Choose a date. If a step asks for two actions, split it into two steps.
Keep the wording to a single sentence. People read a tour while they are working, so a long paragraph pulls their attention away from the screen. Name the thing on the screen using the same words the button uses. If the button says Save draft, do not write Store your work for later.
Show the real button rather than describing it. A highlight placed on the actual control tells people where to look straight away. A sentence that says click the blue button in the top right depends on the person's screen size, their browser and whether they have already scrolled. The highlight does not.
When you write the script, note the target for each step, not just the wording. A good step has three parts: the message, the element it points at and the action that moves the tour on.
Decide when to let people skip, pause or come back later
Experienced users will not want a tour they have already seen. Give them a clear way out. A visible skip option on every step is the minimum, and a way to end the whole tour for good is better.
Pausing matters just as much. Someone may get a phone call halfway through, or need to check a figure in another tab. If the tour can be paused and picked up later, they will return to it. If it disappears when they leave the page, they will often not bother to start again.
Think about coming back later too. A tour that offers to resume the next time someone opens that part of the app is more helpful than one that either repeats itself every visit or never appears again. Decide in advance whether each moment should show once, show again after a change, or be available only on request from a help link.
Write these decisions down before you build anything. They shape how the tour behaves, and they are much easier to set at the start than to fix after people have complained.
Two ways to add it: one script tag or the browser extension
There are two routes into a live guide, and the right one depends on whether you control the site.
If you control the web app, you add one script tag to its pages. Once it is in place, the guide runs in the app itself, and you manage the steps from HandHoldly rather than changing your code each time the tour changes.
If you cannot change the site, perhaps because it belongs to a supplier, a partner or a system your team uses but does not build, you can use the browser extension instead. It lets you run the same guide on sites you cannot edit. This is useful for internal teams who need to show staff how to use a third-party tool, and for support teams who want to guide customers through a page they have no access to.
Both routes use the same script, so you do not need two versions of the tour. Choose the route that matches your situation, test it on one page, and then extend it.
What to do when a button moves
Every product changes. A button gets moved, renamed or hidden behind a new menu, and a tour that pointed at it stops making sense. The question is how you find out.
HandHoldly runs scheduled re-checks every night. When a step no longer finds the element it points at, the check flags that step, fires your webhooks and emails the owners of the script, naming the step that has broken. That gives your team a specific place to look in the morning rather than a vague sense that something might be wrong.
Re-checks flag a broken step. They do not fix it on their own. Someone still needs to look at the step, decide what the new correct version is and update the script.
If you want help with that update, AI is available and is optional. When it is switched on, it can find the moved or renamed button and draft a fix for the step. The draft is for your team to check before anything changes. If it is right, you save it into the script with one click. If it is not, you edit the step by hand.
Build a short routine around this. Decide who receives the nightly alert, how quickly a broken step should be fixed and who signs off the change. A tour with a named owner and a clear route for fixes will stay useful far longer than one nobody is responsible for.
A short checklist before your tour goes live
Run through this list before you switch the tour on for real users:
- Each moment has a clear goal that you can state in one line.
- Each step asks for one action only.
- Each sentence uses the same words as the button or field on screen.
- Every step highlights the real element, not a description of it.
- There is a visible skip option and a way to end the tour.
- Pausing and resuming work, and you know what happens when someone returns.
- You have chosen the route that fits your situation: the script tag if you control the site, or the browser extension if you cannot change it.
- You have tested the tour on the screen sizes and browsers your users actually use.
- Someone is named as the owner of the nightly re-check alerts.
- You know who checks and approves a fix when a step breaks.
If you want to see how one script becomes a live guide in the app, alongside a narrated video and a help article, see how it works.