QAIYU Chatbot

Most support questions are the same twenty questions. A chatbot earns its place by taking those, around the clock, and by getting out of the way for everything else.

The failure mode is a bot that answers confidently and wrongly. That costs more than no bot at all, because the customer acts on the answer. So the setup matters more than the model: the bot answers from your own documentation, and where the documentation is silent it says so and passes the conversation on.

The list of unanswered questions is the real product

Every question the bot could not answer is a gap in your documentation, written in the words your customers actually use. That list is worth more than the deflection rate, because it tells you what to write next.

What we need from you

Whatever you already have in writing: a help centre, a manual, past support threads, an internal wiki. Thin documentation makes a thin bot, and no model fixes that.

Deflection rate is the wrong number to optimise

The metric most support bots are sold on is the percentage of conversations resolved without a human. It is easy to measure and easy to game, and on its own it says nothing about whether customers were helped.

A bot that answers everything confidently scores brilliantly on deflection and destroys trust one wrong answer at a time. A bot that gives up too easily scores badly and costs nothing. The number that actually matters is how many escalations arrived with enough context that the person could resolve them immediately, and that is the number this setup is built around.

Multilingual, with a caveat worth hearing

A chatbot can answer in as many languages as you need, and doing so costs far less than staffing support in each of them. That is a genuine advantage and it is why multilingual support is usually the first thing companies want.

The caveat: an answer is only as good as the documentation behind it, and documentation is usually written in one language. Answering a Spanish question from an English source works, right up to the point where the source is ambiguous, and then the ambiguity gets translated too. For anything with legal or financial consequences, the source should exist in the language the answer is given in.

Where the handover goes

An escalation has to arrive somewhere a person will actually see it, which in practice means your existing inbox, helpdesk or chat tool rather than a new dashboard nobody opens.

That sounds obvious and it is the most common reason support automation quietly fails. A separate queue is a queue that gets checked twice a day, and a customer who was told a human would take over does not experience “twice a day” as a handover.

What it will refuse to do

The agent does not invent policy. Where your documentation is silent, it says so rather than reasoning its way to a plausible answer, because a plausible answer about a refund policy is worse than no answer.

It also does not negotiate, approve exceptions, or handle a conversation where someone is upset. Those go to a person immediately, and the trigger for that is part of the boundary rather than something the model decides in the moment. Where exactly that line falls is agreed in stage two of how a project runs.

Where this fits

A support chatbot is most often the first thing a company automates, because it is bounded and the effect is visible within weeks. The reasoning behind drawing a boundary at all, rather than automating as far as the technology allows, is set out in why an agent instead of a tool. Book a demo to see one answering from documentation like yours.