A chat button that answers from your own material instead of guessing

The problem

A general model asked about your refund policy will produce something that reads like a refund policy. It will have the right shape, the right tone and the wrong terms, and the visitor has no way to tell. That is the failure mode retrieval exists to fix. It is also why most site chatbots get removed a few months after launch: the support load did not go down, and now somebody has to check the answers.

The second reason they get removed is duller. A chatbot that needs an integration project has to be scheduled against everything else the team is doing, and it loses.

What we built

A button. That is most of the appeal, and it was a deliberate constraint — anything that has to be scheduled does not get installed. Three steps: choose how the button looks, give it the documents and pages it should answer from, embed it. There are Chrome and WordPress builds for the sites where even an embed snippet is friction.

Behind the button, answers come out of the customer's own pages, products and policies rather than out of whatever a general model happens to have absorbed. The interesting problem is not the first answer. It is the answer six months later, after the pricing page has changed twice.

Anything that came from a URL is re-read on a schedule: a page that has not been checked in the last twenty-four hours goes back through the crawler, and answers start using the new wording as soon as it lands. When a day is too long to wait — a price that changed this morning, a policy that changed under legal advice — re-indexing that page is a button, not a support ticket.

What it changes

An answer drawn from the customer's own pages can be checked. When one comes out wrong, the page behind it is wrong, or missing, or quietly contradicts another page, and that is a problem somebody can fix in an afternoon. A general model that invents a plausible refund policy leaves nothing to fix.

There are no deflection figures in this section. The ones we have come from individual accounts with different content, different traffic and different ideas about what counts as a question answered, and an average across them would describe the mix of customers rather than the product. A number we would have to explain that hard is not evidence.

Operating it since 2023

The first commit is April 2023. Every dependency in it has been replaced at least once since, on our schedule rather than the customer's.

The model behind the chat changed in April 2025, and every answer shape that had been tuned against the old one had to be checked against the new. That is the migration a buyer expects to hear about.

The ones that actually consumed the time were duller. A form library deprecation in the first month. An HTTP status constant renamed underneath us, which took two passes to clear because the first missed a caller. An admin check that had to be pulled out of every place it had spread to. A CI runtime deprecated out from under the build, moved before it stopped rather than after. None of that was visible to a customer, which was the point: it is the work that stops the visible kind from happening.