Answered in a second
Questions your content already covers never reach a person at all. The ones that do arrive with the detail already collected.
Answers only from your content
The support agent that knows when to stop talking.
One script tag puts it on your site. It answers from your own pages, files and data — and the moment a question goes past them, it says so and opens a ticket in the system your team already uses.
- One script tag, no build step
- Tickets land in your system
- It never guesses
1line of script to install it
6kinds of content it can read
24databases it reads directly
0answers it will invent
01 Ask it something
Pick a question and watch what it does.
Two of these your content covers. The third it does not — and that is the one worth watching.
These replies are written down, not generated: this page has no model behind it. It is the behaviour that is real — answer from the content, or stop and raise a ticket.
02 The problem
Your team already wrote the answers.
They are in a help page, a PDF, a policy, a ticket somebody answered last March. Nobody reads them before writing in, so somebody on your side types the same reply for the twelfth time this week.
Right, or honest
It answers from your content or not at all. With nothing to go on it says so in your own words, and offers a ticket.
Into your own tools
Tickets are posted to an endpoint in your project, with your fields and the visitor’s files. Nothing new for your team to check.
03 The difference
Most bots fail by answering.
A confident wrong answer about a refund window costs you the customer and the trust behind them. Here is the same question, answered two ways.
Fluent, and wrong
“Yes, we can certainly expedite that refund for you today!”Invented. Nobody on your side agreed to it, and now a person has to walk it back and apologise for a machine.
Narrow, and true
“That is not something your policy covers, so I will not guess. Shall I pass it to the team?”The sentence you wrote, for exactly this case — then a ticket with the whole conversation attached, in your own system.
The fallback sentence is yours to write. The agent never improvises around it.
04 The second after they hit enter
It does not go away and think about your business.
Five steps, every time, in about a second. Step four is the one nobody else ships.
- 01Find the passagesYour indexed content is searched for the closest passages. Nothing else is in scope.
- 02Mask what is personalEmails, phone numbers and card-shaped numbers are masked before the model sees any text.
- 03Answer from those onlyWritten from the passages found, in whatever language the visitor wrote in.
- 04Or stop, and say soNot covered? It returns your fallback sentence and offers a ticket. It does not improvise.
- 05Record what it costTokens and cost written against the conversation, so the month is a figure you can read.
05 Setting it up
Live on your site this afternoon.
Three things once. Only the last half of step three wants a developer.
-
01
Add your website
Name it, list the domains the chat is allowed to run on, and choose a layout and colour. Requests from anywhere else are refused, so your widget cannot be lifted onto another site.
-
02
Give it something to read
Point it at a sitemap or a single page, upload a
.txtor.md, or just type. It also reads straight from your own database or a JSON API — read-only, with personal details masked before anything reaches the model. It re-reads on a schedule and retires pages that disappear. -
03
Paste one line, and point the tickets somewhere
One
<script>tag and the widget appears. For tickets to land in your own system, somebody builds the endpoint that receives them — we give you the exact shape and a test button that proves it works before anything is live.
06 How it looks on your site
Six widget layouts, in your colours.
The same agent behind all of them. Pick the one that suits the page it sits on, set your brand colour and bot name, and preview it before it goes near your site.
Classic
A floating chat window above a round launcher button.
Sidebar
A full-height panel docked to the right edge of the page.
Spotlight
A centred dialog over a dimmed page, with flat document-style messages.
Tab
A vertical "Chat with us" handle on the page edge opens a slim panel beside it.
Persona
A big avatar hero; the bot speaks in plain text and the visitor replies in pills.
Messenger
A message pill beside the launcher, an identity card, plain bot text and an expand button.
07 What it reads
6 kinds of source, mixed however you like.
The agent is only as good as what it is allowed to read, so most of the work has gone here rather than into the conversation in the middle.
- A whole website, by sitemap
- A single page
- A file you upload
- Text you type
- Your own database
- A JSON API of yours
PostgreSQL, MySQL, SQL Server, Oracle, BigQuery, Snowflake, MongoDB, Redis and more, over a read-only connection. Related tables are folded into one document, so a ticket arrives with its replies.
08 What it does
Everything the hard part needs.
The things that decide whether a support agent is usable in public, rather than a demo.
01
Reads your whole site
Crawls a sitemap with include and exclude rules, re-reads on a schedule, updates what changed and retires what is gone — and holds back a mass removal until you confirm it.
02
Reads your data
PostgreSQL, MySQL, SQL Server, Oracle, BigQuery, Snowflake, MongoDB, Redis and more, over a read-only connection, with personal details masked before text reaches the model. Related tables are folded into one document, so a ticket arrives with its replies.
03
Tickets in your system
Not another inbox. The chat collects email, the problem and whatever extra fields you define, shows a summary to confirm, then posts it to an endpoint in your own project.
04
Know who you are talking to
Optionally make a visitor prove an email with a one-time code before they can write. A ticket then carries the address they proved, not whatever was typed.
05
Answers in their language
Whichever language the visitor wrote in, in the script they wrote it in — including a language typed in Latin letters. Worked out from their latest message, not from your content.
06
What every reply cost
Each AI call is recorded against the chat it ran for, with its tokens and cost, so a month is a number you can read rather than a surprise.
Will it make things up?
It answers from the content you gave it. When a question is not covered, it does not guess — it falls back to the sentence you wrote for exactly that case, and offers to raise a ticket.
Where do tickets actually go?
To an endpoint in your own project, as JSON with a bearer token you set. Your fields, your database, your workflow. We show you the exact prompt to build that endpoint, and a test button to prove it works before anything is live.
Does it work on any website?
Yes. It is one script tag — no framework, no build step, no npm. You list the domains it may run on, and requests from anywhere else are refused.
What happens to my customers’ data?
Database sources are read over a read-only connection, and emails, phone numbers and card-shaped numbers are masked before text reaches the model. Files a visitor sends are kept in a private bucket and opened through short-lived links.
Can my team step in?
Any time. Open the conversation in the dashboard 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.
Put it on your site and ask it something.
Add a website, point it at a page, paste the script. If it cannot answer your own questions, you have lost an afternoon — not a quarter.