Product tours for apps and websites.

Product tours software lets you build guided walkthroughs that run on top of your own interface. In Gleap, a tour is a sequence of steps anchored to elements of your web app: message steps, pointer steps and video pointer steps. You build it in a visual editor with the Gleap SDK installed, and it runs for the users you target.

Three: message, pointer and video pointer. A message step is a centered card, a pointer step is anchored to an element, and a video pointer plays a short clip beside it. Each step advances on Next, on a click of the target element, or on an input, and you can show a Back button and let users dismiss the tour.

A tour starts by rule, by link, by code or from a Kai Support suggestion. Rules combine an event trigger, page rules and audience conditions with a frequency: send once, or every time the rules match. You can also start a tour from a URL parameter, from the SDK, from a checklist step, a banner or an info card button.

Yes. Enable Kai Support suggestions on a tour and write a short description of what it shows. When a customer asks a matching question in the widget, Kai Support offers the tour with a button, and the tour starts from its configured start page. Your team authors the steps and keeps them current.

A co-browse tour guides the user screen by screen with authored actions. It points at elements, clicks them or types a prepared value, waits for the user's own input where needed, and can read each step aloud with a synthetic voice. It is a prepared walkthrough your team builds, not remote control of the user's session.

Only once. A developer installs the Gleap JavaScript SDK; after that, your team selects elements and writes steps in the visual editor. Engineering helps with stable anchors: the SDK supports data-gleap-tour attributes so a step survives markup changes. See the product tour documentation.

No. The editor opens your website with the SDK installed and stores CSS selectors or data-gleap-tour anchors. Nothing is written to your code base, and tours are served to users by the SDK at runtime.

No. Product tours run in the JavaScript SDK on websites and web apps. Native iOS, Android, React Native and Flutter apps use the other Gleap engagement formats, such as in-app banners, info cards, checklists, push notifications, news and surveys. Talk to us if you need guidance in a native app.

Gleap shows tours sent and tours completed per tour. Combine those with the product event you want users to reach and with the questions arriving in support to judge whether the tour did its job.

A tour is a sequence of steps on the interface. A tooltip explains one element on hover. A checklist is a list of tasks with actions and progress. An info card is a modal with media and a button. All four share customer records and audience targeting, with delivery controls that depend on the format, audiences and customer records in Gleap.

Yes, as drafts. An agent connected to the Gleap MCP server writes tour steps on CSS selectors it knows, for example from your code, and targets the tour by page, events and contact attributes. Open the draft in the tour builder to check every step on your live app before you publish.

They share the customer record with support. A user who gets stuck asks Kai Support in the same widget, and a bug found mid-tour becomes a ticket with session replay attached. See how the platform shares context and how Gleap closes the loop from report to shipped fix.

Gleap fits when tours should sit next to support, feedback and the chat in one widget, on one customer record. Teams that need deep product analytics or an enterprise adoption platform may keep a dedicated tool. Compare Gleap vs Userpilot, Gleap vs Appcues, Gleap vs Pendo and Gleap vs WalkMe.

Product tours are part of outbound messaging, included from Team ($149 per month, billed annually), with unlimited seats. See pricing for plan details.