A live guided tour for web app is a short sequence of highlighted steps that appears inside your web app while someone is using it. A tooltip points at the button to press, a single sentence explains what it does, and the next step waits until the person is ready. It appears where the work happens, not on a separate page.
That makes it different from the other formats you may already use. A narrated video is watched, usually before someone starts, and it cannot respond to what is on their screen. A help article is read, and it only helps if the reader can match its words to the screen in front of them. A live guide sits on top of the real product and walks alongside the person. Hand Holdly builds all three from one script, which is covered further down.
Choose the moments that matter: first login, first task, and the point where people usually get stuck
A tour works best when it is short. Pick three moments rather than trying to explain the whole product.
The first is the first login. What does a new person see, and what is the one thing they should do next? The second is the first task: the core job your product exists to do, such as creating a record, sending an invoice or booking a slot. The third is the point where people usually get stuck. Ask your support team which screen generates the most questions, and check where people tend to leave a process partway through.
Start with those three moments. Once they work well, you can add more, but a long tour that nobody finishes helps no one.
Keep each step to one action and one sentence
Each step should ask the person to do one thing and explain it in one sentence. 'Select the customer name to open their record' is a good step. 'Select the customer name, check the billing details, then choose the right plan' is three steps hiding in one.
Write the sentence as you would say it to a colleague sitting beside them. Avoid internal labels that only your team uses. If the button says 'Save changes', say 'Save changes', not 'Commit your edits'. Matching the on-screen wording is what makes a tour feel natural, and it also makes it easier to check later whether the step still matches the product.
When to start a tour automatically and when to let people choose it
Some tours suit an automatic start. A first-login tour for brand-new accounts is the clearest example, because the person has no context yet and is likely to welcome a short introduction.
Other tours work better when the person chooses them. A task-level guide, such as how to set up a recurring report, is most useful when someone has decided to do that job. Put it behind a help button or a menu item, so it appears when it is wanted.
As a rule of thumb, avoid starting the same tour on every page visit. Repeated interruptions quickly become noise, and people learn to dismiss everything. Decide your trigger for each tour before you write it, and treat a tour that people keep closing as a sign that the trigger or the content needs another look.
How the live guide is added: one script tag, or the browser extension on sites you cannot change
If you control the code of your web app, the usual route is one script tag. Add it to the shared layout so it loads on the pages where the tour should run. Test it on a staging copy first, then check the live pages once it is in place.
If you cannot change the site, for example because it is run by another team or a supplier, you can use the browser extension on those sites instead. It is designed for situations where editing the page is not an option. Whichever route you choose, confirm which pages the guide will appear on before you publish, so there are no surprises for users.
How one script feeds the tour, the narrated video and the help article, so wording matches everywhere
The most practical benefit of planning a tour carefully is that the same wording can serve three formats. Hand Holdly takes one script and produces a live guide inside your app, a narrated product video and a step-by-step help article. Because they share the same steps, a customer who watches the video, reads the article and then opens the app sees the same names and the same order.
This also simplifies translation. You can translate product help into other languages, and if you later change one sentence, only that line is re-voiced in the video. The voices are British by default, and you can choose a natural voice after hearing a sample. Voice quality and translation are good starting points, but they are not perfect, so it is worth reading through the output in each language with a native speaker before you publish.
Safety defaults: delete, pay and send buttons are refused unless a step says otherwise
A tour should guide people, not nudge them into actions they did not mean to take. Hand Holdly refuses to target delete, pay and send buttons unless a step says otherwise. That default is there so that a tour cannot accidentally point someone at an irreversible action.
When you plan your steps, keep destructive and financial actions out of the tour unless they are the whole point of the lesson. If one does need to be covered, state it clearly in the sentence so the person knows what will happen. Personal data is also blurred in the video, screenshots and article, so recordings of your own data are less likely to be shared by accident.
How nightly re-checks flag a step that no longer works and email the owners naming it
Products change. A button moves, a menu is renamed, a screen is redesigned. Every night, Hand Holdly re-checks the steps in your scripts against the live product. If a step no longer matches, it is flagged, your webhooks fire, and the owners receive an email naming the step that needs attention.
Re-checks flag problems; they do not fix them on their own. That is deliberate. You decide what changes to make.
If you switch on AI, it can help with the work that follows a flag. It can find a button that has moved or been renamed and draft a suggested step. You check the suggestion, and if it is right, you save it into the script with one click. AI drafts are there to speed up your review. They are not always right, so treat them as a starting point rather than a finished answer.
For the owners of each script, the practical point is to name a person or team for the re-check emails. A flag that reaches nobody in particular is easy to ignore.
A short checklist to plan your first tour
- Choose three moments: first login, first task and the point where people usually get stuck.
- Write one action and one sentence for each step, using the wording on your screen.
- Decide whether each tour starts automatically or when someone chooses it.
- Decide how the guide will be added: one script tag, or the browser extension on sites you cannot change.
- Check that no delete, pay or send button is in a step unless the step says so.
- Name the owners who receive re-check emails for each script.
- Read the video and article wording to make sure it matches the live guide.
- Plan around monthly allowances for live guide sessions. When an allowance runs out, new production pauses and nothing is billed automatically.
If you would like to see how one script becomes a live guide, a video and an article, See how it works.