Skip to content
End to end

From a script tag to an answered question.

Three things to set up, and then one path that every question follows — including the part where the agent gives up and fetches a person.

01 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. 01

    Add your website

    Name it, list the domains the chat may run on, pick one of 6 layouts and your brand colour. The preview shows the real widget before anything goes near your site, and requests from any other domain are refused.

  2. 02

    Give it something to read

    A sitemap, a single page, a file, typed text, your own database or a JSON API. Mix as many as you like on one website; it re-reads on a schedule, updates what changed and retires what disappears.

  3. 03

    Paste one line, and point the tickets somewhere

    One <script> tag and the widget appears. The ticket endpoint is the only part that wants a developer — and the only part that puts answers into the system your team already opens.

That one line
<script src="https://chat.yoursite.com/widget.js" data-client-id="your-id" async></script>

02 What it can be told to read

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

24 database engines, over a read-only connection, with personal details masked before anything reaches the model. Related tables are folded into one document, so a ticket arrives with its replies.

03 The second after they hit enter

It 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. Five steps, every time, in about a second.

  1. 01Find the passagesMatched against your indexed content. Nothing else is in scope.
  2. 02Mask what is personalEmails, phone numbers and card-shaped numbers go before the model sees any text.
  3. 03Answer from those onlyIn whatever language the visitor wrote in, in the script they wrote it in.
  4. 04Or stop, and say soYour fallback sentence, and an offer to raise a ticket. It does not improvise.
  5. 05Record what it costTokens and cost written against the conversation it ran for.

04 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 — into your system, not ours.

What that costs
What your endpoint receives
POST https://yoursite.com/api/support/tickets
Authorization: Bearer <a token you set>

{
  "email": "[email protected]",
  "subject": "Expedited refund request",
  "body": "Visitor asked whether a refund can be...",
  "transcript": [ ...the whole conversation... ],
  "attachments": [ "https://.../receipt.png" ],
  "order_id": "A-10294"
}

05 What your team sees

A dashboard for watching and stepping in.

Not somewhere to live. Four things, and then you can close the tab.

Every conversation

Across all your websites, newest first, with what was asked and what was answered.

Step in and type

Your reply reaches an open chat straight away, and their history if it has closed.

What it knows

Every document, where it came from, when it was last read, and whether it is live.

What it cost

Replies and spend per website, per day, with the cost of each call recorded.

It takes an afternoon to know.

Point it at one page and ask it the question your team answers most. That is the whole evaluation.