Your product just learned to onboard its own users.

One script tag in your app's layout, on the pages where logged-in users work. No SDK, no build step, no framework dependency. The tag loads the guide, and you configure everything else from the Help Sherpa dashboard: which pages and controls it may use, what it says, and how it sounds.

If it renders in a browser, yes: React, Vue, Svelte, Angular, Rails, Django, Next, plain HTML. Single page apps are fine; the conversation follows route changes and survives full page loads. What it needs from you is stable selectors for the controls you want it to use, which is a configuration step, not a code change. A few control types are not supported yet, such as custom dropdown components and file pickers.

The script tag takes minutes. A useful first configuration takes an afternoon: name the pages and controls that matter, write the brief, and either write a couple of playbooks or record yourself walking through the product while the guide's interviewer asks you questions. Nothing goes live until you review and publish it. Design partners do this with us on a call.

The guide has a mobile layout for the conversation, but the hands-on part, the cursor driving your product, is built and tested for desktop browsers first. If most of your users are on phones, tell us; we will be honest about fit.

Each control the guide uses is named by a stable role with a selector you choose. If a selector breaks, that action fails visibly: the guide tells the user it could not find the control and stops, and the session recording shows exactly which role failed so you can update it. We recommend data attributes over class names so redesigns do not break the map. Automatic detection of broken selectors is on the roadmap.

Only what you configure. You name each control the guide may use, give it a stable selector and say what actions are allowed on it: open, click, type, choose. You can also block keywords, URLs and selectors outright, and those blocks always win. Anything you have not named, the guide cannot act on. Before every action it moves a visible cursor to the target, outlines it, then acts, so the user can watch and stop it.

By default, no. The guide opens pages, clicks navigation, runs searches and reads the screen. Filling and submitting forms is on the roadmap. Most teams start read and navigate only, and add writes once they have watched sessions.

Not yet. Today the guide knows what you teach it: a product brief (what the product is, your vocabulary, topics to avoid), the pages and controls you configure, and the playbooks you write or record. It also reads the parts of the current screen you allow. Connecting a help center or docs site so it can answer from them is on the roadmap.

Yes, today. The user talks, the guide talks back, and a live transcript runs alongside so nothing is lost and the conversation can be read back. There is no typed chat input yet; it is on the roadmap for users who cannot or would rather not speak.

English today. Other languages are on the roadmap; tell us which ones you need.

At any moment. They can talk over it, tell it to do something else, pause it, or minimize it and keep working. The guide never hides itself and never takes an action the user cannot see coming.

Not yet. Today every session, with transcript and actions, is in your Help Sherpa dashboard. Pushing sessions to Intercom, Zendesk, Slack or a CRM, and escalating a live conversation to a human, are on the roadmap.

Your app tells it. When the page loads you can pass the user's email, name, company and plan, and the session is recorded under that identity so you can see which users asked what. The guide does not log in as the user or read your database; it works on the screen your user is already looking at. Today the guide uses identity for reporting. Using it to tailor what the guide says, for example knowing which setup steps a user has finished, is on the roadmap.

Two rules keep it honest. First, it acts only on controls you configured, so it cannot invent a button. Second, it never says a step worked until the browser confirmed it: the right page opened, the right heading appeared, the search returned results. If a step fails, the guide says so and stops. On questions, it answers from your brief and the visible screen, and you can name topics it must not discuss. Every session is recorded, so when it gets something wrong you can see exactly what it said and fix the configuration.

Audio streams to the voice provider in real time for transcription and speech. Transcripts, the actions taken and any page text the guide read are stored so you can review sessions, scoped to your workspace. Values in fields you mark sensitive are redacted before they leave the page. You control which pages and regions it may read at all. Ask us for the current provider terms and retention details before you install; we would rather answer that in writing than round it up here.

Per guided session, not per seat and not per active user. A session is one continuous conversation with one user, however long it runs. Idle and under ten second sessions are free. The free tier covers 100 sessions a month on one product with no card. Paid tiers add sessions, sites and the recorder.

Your transcripts and screen text are not used by us to train models. Where data is stored, which providers process it and under what terms are questions we answer in writing on request, so you can hand the answer to your security reviewer as is.