Guide · September 3, 2026 · 9 min read

An assistant that answers before your team

On a server that receives support requests, the same handful of questions accounts for most tickets. Answering them by hand, ten times a week, wears out a volunteer team more surely than any serious incident.

What an assistant can genuinely absorb

Look at your last thirty tickets. On a community server the split is almost always the same: half repetitive questions — “I paid and got nothing”, “how do I appeal a penalty”, “how do I apply” — and half special cases that need a human.

It is the first half that automation handles well. Not because it is simple, but because it is identical every time: the answer is already written somewhere, often in an announcements channel nobody rereads.

The goal is therefore not to replace the team. It is to give it back the tickets that deserve its attention, by settling the others before it opens them.

What decides everything: the moment it goes quiet

An assistant that answers too much is worse than no assistant at all. Three rules about stepping back are worth more than any subtlety of understanding.

• On opening, it mentions nobody. Pinging the team before anyone even knows what the matter is, is exactly what we are trying to remove. The bot introduces itself, invites the member to state their request, and waits.
• As soon as a human writes, it disappears. For good, including when it thinks it has the answer. Two voices answering the same person, one contradicting the other in public, cost more than every ticket it could have absorbed.
• It does not insist. Two failures and it calls the team. A button allows short-circuiting at any moment: somebody who wants a human must get one without negotiating with a robot.

Do not start from a blank page

The advice that follows — write your entries, work on the rephrasings — is sound, and it was long the only path. It also has a flaw: it assumes you know in advance what members will ask, and that you will word it the way they do. Nobody does that. You write three entries, switch it on, and find out three weeks later that the bot sends everyone to the team.

Yet the material already exists, and it is better than anything you would write from memory: your closed tickets. On every closure, Orius finds the real question — a real member's, with their typos and their words — and your moderator's real answer, the one that settled it. It lands in your panel's “To review” queue as a suggestion. You read it, fix two words, approve it.

Three sources feed that queue. Closed tickets, then. Unanswered questions, grouped by subject: twelve people asking the same thing used to make twelve lines in a list nobody read any more, they now make one, marked “12 people affected”. And entries that answer badly, flagged with the exact phrasings they fail on — the answer is already good, only the words people search it by are missing.

The queue is sorted by how many people are affected, because that is the only question you ask yourself in front of a base to write: where to start.

Writing the knowledge base

An entry is a question and an answer. The temptation is to write the question like a documentation heading; that is where it goes wrong.

Write the question the way a member would ask it. “My rank hasn't shown up after buying” beats “Role synchronisation procedure”. Nobody types the second one.

Then add other phrasings, one per line. It is the most useful field of all, and the least filled in. Two distinct uses:

1. Your server's vocabulary. If your members say “my rank” or “my VIP”, no generic lexicon will guess it.
2. Other languages. A phrasing in Spanish or Portuguese inside an English entry covers an international server without keeping four separate bases.

How the bot understands a badly written question

A member never writes the question the way it was entered. They type “hi i payed but still havnt got my rank” where the admin wrote “How do I get my rank after a purchase?”. Not one word in common in written form.

Direct comparison therefore always fails. What works is to rephrase first: strip accents and digit-for-letter writing, expand abbreviations, reduce words to their stem — “paid”, “payment” and “paying” become the same thing. Then widen with a lexicon of intents: what relates to a purchase, a penalty, a delay, in whatever language.

That last point is what makes “no me llegó mi compra” reach an entry written in English. On OriusBot, all of that computation runs on Orius's infrastructure: no ticket message is passed to an outside AI provider, and there is no API key to supply.

Tuning confidence without guessing

Every match gets a score. Below a threshold, the bot considers it did not understand. That threshold is the only setting that genuinely matters, and it goes wrong in both directions:

• Too low: the bot answers beside the point. The member leaves with a false answer and does not press further — the worst case, because it does not show.
• Too high: it calls the team for questions it could have handled, and stops being useful.

Around 42% suits most servers. But do not tune blind: a test bench lets you try a question without touching a real ticket, and shows the rephrasing the bot actually searched for. That line explains a surprising result far better than a percentage.

Handing over properly

An assistant is judged as much on its failures as on its successes. When it calls the team, it no longer settles for a role mention: it attaches a handover sheet. The original request — the one the member worded freely, before being asked to rephrase — where exactly it stalled, what has already been answered, and enough to judge the tone: account age, when they joined, active warnings.

Repeating what has just been said is the fastest way to lose someone. The member reads that panel, since it is in their own channel: so it carries no score, no entry number, nothing you would not say to their face.

Two settings round out the escalation. The usual reply time is announced to the member — measured on your own claimed tickets, never typed in: a declared delay is wrong by the next day, and wrong in the direction that stings. Nothing is announced while there are fewer than five measurements over thirty days. And your on-duty hours, declared day by day in your server's time zone, let the bot say the team is away and when it returns. A member who writes at 3 a.m. and gets nothing for six hours does not conclude “they are asleep”: they conclude “they do not care”.

The case of twin questions

A high score does not say which entry answers. If the server has “How do I buy the VIP rank?” and “How do I buy the MVP rank?”, the request “how do i buy a rank” matches both — equally.

Picking at random amounts to answering wrongly half the time. The right behaviour is to ask, offering the candidates. It is the gap between the two best entries that triggers that question, not the score.

What the assistant misses, and why that is valuable

It will miss questions. Always. What matters is knowing it: every unanswered question is logged, with the best score obtained.

That list is the raw material of your base. It holds real questions from real members, in their own words — the best possible phrasing for a new entry, and one you would not have invented. Fifteen minutes a week rereading it does more for coverage than two hours imagining questions in advance.

Knowing whether any of it helps

The miss log says what fails. It says nothing about what works — and that is the only question left after an evening spent writing entries. You remember the three times the bot answered beside the point, never the sixty times it settled the matter on its own, and you end up switching off a module that was working.

So the panel shows two figures over thirty days: the share of tickets settled without the team, and the share of answers judged useful by members themselves. Below five tickets no percentage is shown: a rate computed on two measurements is a wrong figure you would remember anyway.

Frequently asked questions

Can the bot invent an answer?

No. It only returns answers written by the server, as they are. It picks which one; it writes none. That is a deliberate limit — an assistant improvising on a server's rules creates disputes instead of avoiding them.

Do entries have to be written in all four languages?

No. One entry per question, in the server's language, plus a few phrasings in other languages if your community is international. The intent lexicon catches a good share of the rest.

What happens if no entry is written?

The assistant stays silent, and even refuses to switch on. A welcome promising help that cannot be delivered is worth less than silence.

Does the member know they are talking to a robot?

Yes, and they must. The assistant introduces itself as such on opening, and every answer carries a note that it is automatic. Letting people believe there is a human always backfires on the server.

Read next : Support tickets, Team rota, Staff CRM: recruiting and running your team.