Support automation · grounded answers
Most support bots fail by confidently inventing your policy.
A bot that makes up a returns window sounds exactly like one that read the policy — same tone, same certainty. There is nothing for a customer to detect. So the fix cannot be a better prompt; it has to be structural.
This agent can only say what your policy says. Every answer quotes the passage it rests on, and the server checks that quotation actually appears in your text before you see it. When the policy does not cover the question, it says so and drafts the handover to a colleague — because "I don't know, here's who does" is a good support answer and a guess is not.
What it based that on
What your policy would need to say
Why this matters more than the answer. Run a week of real questions through it and the gaps list becomes your documentation backlog — written by customers, in the order they actually ask. That is usually worth more than the deflection rate.
How it refuses
Three mechanisms, because a prompt asking politely for grounded answers is not one.
The shape forbids it
An answer and its quotations are one structural unit. A claim with nothing quoted is a malformed response, not a stylistic slip.
Contradictions are rejected
Saying the policy does not cover something and then answering anyway is caught before it renders, not left to tone.
Quotes are verified
Every quotation is checked against your text on the server. A fabricated quote looks like evidence, so that check is not left to the model.
Gaps become work
A question it cannot answer produces a drafted handover and a named gap, rather than a dead end and an apology.
This page answers one question at a time against text you paste. The version worth commissioning sits on your helpdesk, reads your whole knowledge base, and writes back to the ticket. Tell me what your queue looks like and I will say honestly whether it is worth automating.