A whole website
Point it at a sitemap. Include and exclude rules decide what is in scope, and it comes back on a schedule to pick up what changed.
How it works
From a script tag to an answered question.
Three things to set up, and then one path that every question follows. This page walks the whole of it, including the part where the agent gives up and fetches a person.
Setting up
Three things, once.
None of them needs a developer except the last half of step three, and only if you want tickets in your own system — which you do.
-
1
Add your website
Give it a name and list the domains the chat is allowed to run on. A request from anywhere else is refused, so nobody can lift your widget onto their own site and spend your model budget.
Then choose how it looks: one of 6 layouts, your brand colour or a gradient, your bot’s name and logo. There is a preview, so you see it before your visitors do.
- Domains you list, and nowhere else
- 6 layouts, previewed before they go live
-
2
Give it something to read
This is the step that decides whether the whole thing is any good. There are 6 kinds of source, and most teams use two or three.
Website sources are re-read on a schedule: what changed is updated, what disappeared is retired. If a crawl suddenly wants to remove a large share of what you have, it stops and asks you first — a broken sitemap should not quietly empty your knowledge base.
- Read-only on your database, always
- Personal details masked in what it imports
-
3
Paste one line, and point the tickets somewhere
The widget itself is one
<script>tag. No framework, no build step, no package to install. Drop it in your layout and it is live.The other half is the endpoint tickets are posted to. That one does need somebody who can write a small API in your project — we give you its exact shape, the fields it will receive, and a button that posts a test ticket so you can prove it works before a real customer depends on it.
What it can be told to read.
6 kinds of source. Mix as many as you like on one website.
A single page
One address, read and kept current. Useful for a policy or a help article that matters more than the rest.
A file you upload
.txt or .md. The quickest way to get an internal document the agent should know about into it.
Text you type
Paste or write it straight in. Good for the dozen answers that live in somebody’s head rather than on a page.
Your own database
24 engines, from PostgreSQL and MySQL to BigQuery, Snowflake, MongoDB and Redis. Read-only. Related tables are folded into one document, so a past ticket arrives with its replies attached.
A JSON API of yours
Where the data is behind an API rather than a database. You map which fields are the title and the body; it does the rest.
Someone asks something
What happens in the second after they hit enter.
The agent does not go away and think about your business. It looks for the passages of your own content that match what was asked, and answers from those.
- It replies in the language they wrote in — worked out from their message, not from your content, and including a language typed in Latin letters
- Where your content does not cover it, it does not improvise: it says so in the sentence you wrote for that case
- It offers a few sensible follow-up questions, which you can switch off
- The tokens and cost of that reply are recorded against the conversation it ran for
When it cannot answer
It fetches a person, properly.
A dead end is where most support bots lose the customer. Here it is a handover with everything your team needs already collected.
- It offers a ticket rather than repeating itself or looping.
- It collects the email — and where you switch verification on, the visitor proves it with a one-time code, so the ticket carries an address that is real.
- It asks for your own fields, whichever extra ones you defined: an order number, an account id, whatever your team always has to ask for.
- It takes files, if the visitor has a screenshot or a document. They go to a private bucket and travel with the ticket as links that expire.
- It shows a summary and waits for the visitor to confirm it before anything is sent.
- It posts the ticket as JSON to the endpoint in your project. From that second it is in your system, under your workflow.
What your team sees.
The dashboard is for watching and stepping in, not for living in.
Every conversation
Read any chat in full, open or ended, with the ticket it produced if it produced one.
Step in and type
Your reply appears in the visitor’s chat straight away if it is still open, and in their history if it is not.
What it knows
Every document it has read, where it came from, and when it was last refreshed. Delete anything that should not be there.
What it cost
Per reply, per conversation, per month. A number you can read rather than one you find out about.
It takes an afternoon to know.
Add a website, point it at a page you already have, paste the script, and ask it the question your team answers most often.