Chatbot, product tour or in-app assistant: which one takes work off you

A chatbot over your docs takes the questions off you, a product tour helps new users find their way the first time, and neither of them does the task the customer asked for. If most of your inbox is “change this”, “set up that”, “add this person”, you need help that can act inside your app. If most of it is “how does this work?”, you don’t, and a chatbot over good docs is the cheaper and simpler choice.

This post compares the three categories as fairly as we can, including the cases where aside, which is the third kind, is the wrong pick.

What is the difference between a chatbot, a product tour and an in-app assistant?

They do three different jobs, even though they often get compared as if they competed for the same budget.

• A chatbot over your docs reads your help center and answers in a text box. Its job is to answer questions, at any hour, without you. When it can’t, a good one hands over to a person.
• A product tour is a sequence of tooltips, modals or highlights that you design ahead of time and attach to screens of your app. Its job is to show people where things are, mostly in their first days.
• An in-app assistant that runs actions lives inside your app and can do things there. In aside’s case, your page registers a list of actions, which are functions you already have, like invite teammate or change plan. When a user asks for something, the assistant picks one action and its arguments, and your page’s own code runs it: it opens the screen and fills the form where the user can see it. The user presses the button that saves, sends or deletes.

Some support AI agents also go beyond answering. Intercom’s pricing page charges Fin from $0.99 per outcome, and counts as an outcome a resolution the customer confirms or a workflow Fin completes. Those workflows run from the support conversation. The difference with an in-app assistant is where the work happens: inside the customer’s screen, with your code doing it in front of them.

The comparison table

Take one real request and follow it through each tool: “Can you add my colleague Ana as an admin?”

	Chatbot over your docs	Product tour	In-app assistant that runs actions
What the user gets	The steps: Settings → Team → Invite, pick “Admin”	A tooltip on the Invite button, if a tour covers it	The team screen opens, the invite form fills with Ana’s email and the admin role, and the Send button is highlighted
Who does the last click	The user, after following the steps	The user, after following the tour	The user, on a form that is already filled
What you build	Your docs, which you mostly have; the snippet	Each tour, screen by screen, in the tool’s editor	One function per task, with a name, a description and the fields it takes
What keeps it right	Docs that match the current interface	Tours updated every time a screen changes	Your actions’ code, which changes with your app like any other code
Where it stops	Anything the user has to do themselves	Paths you didn’t predict	Tasks you haven’t turned into actions yet
Who can set it up	Anyone who can paste a script tag	Usually product or marketing, no code	Someone who can write a JavaScript function
Typical pricing model	Per resolution or outcome, often plus seats	Per monthly active user	Varies; aside charges per conversation

Two pricing examples, as listed on the vendors’ own pages in October 2026: Intercom lists Fin from $0.99 per outcome, with seats from $29 a month billed annually; Userpilot lists its Starter plan at $299 a month for up to 2,000 monthly active users. Plans at aside start at €49 a month for 200 conversations. Pricing pages change, so check the current ones before you decide.

When a chatbot over your docs is the right choice

Pick a docs chatbot when most of what customers ask are questions, not tasks. “Do you support SSO?”, “what happens when my trial ends?”, “how is usage counted?” have one correct answer that lives in a document, and a chatbot can give it at 3 a.m. in a second.

It is also the right choice when you have no one who can write code for this, because a docs chatbot needs your docs and a snippet, nothing else. And if your support already runs on a helpdesk your team likes, a chatbot that belongs to that helpdesk keeps everything in one place.

Where it stops: the customer still has to go and do the thing. That’s the point where many of them gave up the first time, and the same question, every week is about what happens next: they write in, or book a call.

When a product tour is the right choice

Pick a product tour when the problem is discovery in the first days: new users who don’t know your app has a reports section, or a new feature you want people to notice. Tours are good at “look, this is here”, and the no-code editors let a non-technical person ship one in an afternoon.

Keep them short and let people choose them. Chameleon’s 2024 benchmark report, based on nearly 300 million interactions, puts the average tour completion rate at 33.5%, with five-step tours falling to 21.6%. Tours that users chose to start from a checklist did much better: 64%. A tour nobody asked for, with many steps, is mostly skipped.

Where it stops: a tour shows the way, but the user still walks it, and it only covers paths you designed in advance. When the interface changes, the tour has to change too. Why product tours stop working after the first week goes into this in more detail.

When an in-app assistant that runs actions is the right choice

Pick it when your inbox is full of tasks: the same “change my plan”, “invite my teammate”, “connect the integration”, “create the weekly report” every week, each one easy for you and hard enough for the customer to end up on a call.

There is a fourth kind I tried and dropped: an assistant that reads the screen and decides where to click. The first versions of aside worked that way, and they failed too often to put in front of anyone. That’s why aside now acts only through functions your page registers.

What you write is one function per task. Here is a whole action with aside’s SDK:

const actions = [{
  name: 'invite_teammate',
  description: 'Open the team settings and fill the invite form with an email and a role. '
    + 'It does not send the invite: the user reviews it and presses Send invite.',
  inputSchema: {
    type: 'object',
    properties: {
      email: { type: 'string', description: 'Email of the person to invite' },
      role: { type: 'string', enum: ['admin', 'member', 'viewer'] },
    },
    required: ['email'],
  },
  run: async ({ email, role = 'member' }, aside) => {
    aside.navigate('/settings/team');
    await aside.fill(await aside.waitFor('[data-aside="invite-email"]'), email);
    await aside.fill('[data-aside="invite-role"]', role);
    aside.highlight('[data-aside="invite-send"]', 8000);
    return { filled: { email, role }, next: 'the user presses Send invite' };
  },
}];

if (window.aside) window.aside.register(actions);
else window.addEventListener('aside:ready', () => window.aside.register(actions), { once: true });

The model only sees the name, the description and the input schema, and only chooses which action to run and with what arguments. It never sees your DOM and never decides where to click: the handler is your code, selecting controls by their data-aside attribute. And the handler stops before the button that sends; the user presses it. How to let an assistant act inside your web app without handing it the keys covers how to choose which actions to expose and how to write them safely.

The same assistant also answers questions from your docs, says when it doesn’t know, and hands the conversation to your team (aside’s inbox, Slack or a webhook) when it can’t solve something. So in practice it covers the chatbot’s job too.

When aside is not the right choice

Being fair means saying where we don’t fit. You probably don’t need aside if:

• Your inbox is almost all questions. If tasks are a small share, a docs chatbot or better docs will do most of the work for less.
• Nobody on the team can write a function. Answering from docs is one script tag. Acting inside your app needs someone who writes the actions, because it is your code that runs.
• You need it inside Intercom or Zendesk. It is its own panel inside your app and can sit next to them, but there is no Intercom or Zendesk integration today.
• Your customers need phone or voice support, or languages other than English and Spanish. It works in text, in English and Spanish.
• The task needs your team’s judgment. A refund exception or a custom contract shouldn’t be an action for a customer to trigger. It hands those to a person, which is the right outcome, but it doesn’t take that work off you.
• What you want is onboarding announcements and adoption analytics across a large user base, with segments and A/B tests. That’s what product tour and adoption platforms are built for.

How do you decide which one you need?

Open your inbox and sort the last 30 conversations into questions and tasks (here is a 20-minute method). Then read the result:

What you find	What to try first
Mostly questions	A chatbot over your docs, and fix the docs it can’t answer from
Mostly confusion in the first week	A short product tour that users can start themselves
Mostly repeated tasks	An in-app assistant with actions for your three most repeated tasks
A mix	Start with whatever covers the biggest pile, then measure again

If you want to put a price on each pile before deciding, what founder-led support really costs has a table you can fill with your own numbers.