The customer is answered
It reads the way your team writes, because that is where it came from. No queue, no wait, and no reason to go asking for a person.
Four steps sit between a customer's message and the reply they get. This page walks through each one, including the parts we deliberately do not claim.
"How much is it?" on its own means nothing. Read against the chat so far it means "how much is the yearly plan". That is the question we go looking for.
Not a help article. The reply one of your own agents sent to that question, out of your support history. There is nothing for you to write first.
Their order, their plan, their delivery date, read live out of your system and dropped into the reply by code. The model never writes those values, so it cannot invent one.
Is there a close enough answer, and is it about the same thing this customer asked about. A similarity score can only tell you the first one.
It reads the way your team writes, because that is where it came from. No queue, no wait, and no reason to go asking for a person.
Before the customer ever sees a guess. Your agent gets the draft, the history and the reason it stopped.
Your support history. Every question a customer asked, paired with the reply your agent actually sent. There is no content to write and no tone to configure, because the voice in the answer base is already your team's. If a question has no close match, that absence is itself the signal, and the conversation goes to a person rather than to something improvised.
"How much is it?" means nothing on its own. Before anything is matched, the question is rewritten against the conversation so far, so it becomes "How much is the annual plan?" and gets matched on what the customer really meant. If that step is unavailable, the original text is used instead of guessing.
A relevance score answers "is anything similar here?" It does not answer "is this about the same thing?" A stored answer about Philadelphia's Sunday hours scores highly against a question about New York on Wednesday, and clears any reasonable threshold. So a second, separate check confirms the entities match before anything is sent. Those are two different guarantees and we treat them as two.
When both checks pass, the reply that goes out is built on the stored answer rather than written fresh. A model is used to pick which stored answer applies, and it returns an identifier rather than prose. That is also why prompt injection has little to work with: the worst a hostile message can do is cause a handoff or surface a real answer that does not fit, rather than text an attacker wrote.
A person picks it up with a draft already prepared from the closest stored answers and your company fact sheet, shown only to them and never sent on its own. Every escalation records why it happened, so the reasons are countable rather than something you have to read logs to find.
The engine stores no messages. Your CRM stays the system of record, and it is handed the recent context on each call. One practical consequence: a team adopting it mid-life works from the first call, with no backfill and no empty-history ramp.
We do not promise zero wrong answers. A stored answer can still be applied to the wrong question, and we treat that as the residual risk rather than pretending it away. We do not detect personal data, we take no actions in your systems, and we make no promise about how your customers will feel. What we describe is the mechanism.
Tell us what you run today and how your team handles support. We will walk you through what this would look like on your own history.
We will get back to you about setting it up on your support history.