Answer Support Tickets with Tour Links

Overview

Most support answers are directions: "Go to Settings → Team, click Invite, enter their email…" The user reads them in one tab and tries to follow along in another, and half the back-and-forth in a ticket is them getting lost between the two.

A tour link replaces the directions. It's a plain URL into your app with ?tour= appended — opening it starts a guided tour that spotlights each element and waits for the user to actually click it, on their own account, with their own data:

https://app.yourproduct.com/settings/team?tour=1

Paste that into a canned response once, and every future "how do I invite a teammate?" ticket is answered by the product itself.

Make a flow linkable

A tour link needs two things on the destination page: the tour player, and the tour it should run.

Hosted tours: put the snippet from stepshots tour push on the page where the flow starts, naming that flow's tour id:

html

<script
  src="https://stepshots.com/tour.js"
  data-stepshots-tour="your-tour-id"
  defer
></script>

The link is that page's URL plus ?tour=1 (or ?tour=<tour-id> — equivalent, just explicit). The ?tour= parameter launches the tour named on the page's script tag, so give each linkable flow's start page a tag naming its own tour.

Self-hosted tours: build your registry and boot the player globally:

stepshots tour build -o public/tours.js

With the registry loaded on every page, ?tour=<key> launches any tour by its key, from any page — /dashboard?tour=upload-demo, /settings?tour=create-api-key, and so on. If you're deep-linking to many different flows, this is the more flexible setup.

What the recipient sees

A tour link is built to behave well in a support context:

It always runs. The once-per-browser flag and any data-when gate are ignored — a returning user who saw the onboarding tour months ago still gets the walkthrough.
It starts fresh at step 0 and advances only on the user's real clicks and typing, so they end up having done the thing, not watched it.
It survives the flow. Progress is kept per-tab, so page loads and SPA navigations mid-flow resume at the current step instead of starting over.
It's dismissable. Skip or Escape ends it — the link never traps anyone.

If the target element genuinely isn't there (a permissions gap, a plan limit), the tour shows a friendly "lost the trail" card instead of hanging — a useful signal in itself when a user reports it back.

Note

On hosted tours, ?tour= runs are treated as previews and are excluded from your tour analytics — the funnel keeps measuring organic runs only, and support-driven walkthroughs don't inflate it.

Write the macro

Add the link to your canned responses (Zendesk macros, Intercom saved replies, Front templates, plain-text snippets — anywhere). A shape that works:

Happy to help! The quickest way is to let the app walk you through it — open this link and follow the highlights:

Invite a teammate →

It runs right in your own account, and you can press Escape at any point. If a highlighted button doesn't appear for you, let me know — that usually means a permissions issue on our end.

Three guidelines for the tours behind the macros:

One tour per top ticket driver. Pull your five most common "how do I…?" tickets and author a tours/<key>.tour.json for each — that's an afternoon of work that answers tickets forever after.
Instruct, don't describe. Callouts in a support tour are instructions: "Click Invite member", not "Here you can see the invite button".
Keep it to the fix. Start the link on the page where the flow begins and end the tour at the moment the user's problem is solved.

The same tours double as "Show me" buttons in your FAQ and help center — author once, deflect twice.

Keep the links from rotting

A support macro lives in your helpdesk for months; the UI under it keeps changing. Two mechanisms keep old links working:

Fallback anchors. Each step carries the target's recorded text and aria-label, so a renamed class or reshuffled DOM doesn't break the walkthrough.
tour check in CI. Replay every tour headless against staging on each deploy, and a selector that stopped resolving fails the build before a customer clicks a dead link:

stepshots tour check --url https://staging.example.com --fail-on warn

See CI & Automation for wiring this into a pipeline (there's a ready-made GitHub Action), and Guided Tours for the Pro drift alerts that flag a tour whose runs keep getting lost in production.