What AI Cannot Do in Support: Will Not, Cannot, and Does Not Exist

Almost every AI support page lists what the thing can do. That is not much help when you are deciding whether to put a bot in front of your members, because the question you are actually asking is narrower and more nervous. What will it do that I would not want it to?

This is the inverse page: the rules our own AI runs under on every ticket, plus the parts of the product we have not built.

What can an AI support bot not do?

Three, and telling them apart is most of the work.

The middle row is the most common, and the one people mistake for the bottom row. An AI that was never told your refund window will not invent one, so it escalates, and a week of that reads exactly like a product that does not work. Do AI ticket bots actually work takes that apart with numbers.

This article is about the other two. The top row first, because nobody publishes it.

What is the AI not allowed to do?

A refusal you can rely on is worth more than a capability you cannot check. These are ours, and they hold on every ticket on every plan.

Two of those need a sentence more.

The response time rule is the least obvious and the most useful. Ours cannot tell a member somebody will be with them in ten minutes, because nothing in the product can hold that promise. No Discord ticket bot has an SLA timer, ours included, and response times you can actually keep covers what to say instead.

The closing rule has an exception. If the member asks to close, that request is the confirmation and the ticket closes there and then, because asking somebody to confirm what they just said is irritating. The wait applies only when the AI raises it, and then it needs a clear yes on a later turn. "Ok" and "thanks" never count.

That is the only guardrail here that is structural rather than written as an instruction, and the difference matters. An instruction can be argued with, patiently, over twenty messages. A parameter the model was never given cannot be supplied.

When does the AI stop answering?

For seven reasons, and the ticket records which one applied, so a staff member can always see why it went quiet.

The second row is the one to plan around. The AI stands down the moment any human posts, which is what stops the two of you answering the same member at once. It also means a staff member typing "looking into this" has switched the AI off for the rest of that ticket.

The fifth row sounds alarming and is not. When a server runs out of AI allowance the AI stops cleanly and the ticket carries on by hand, with no degraded replies and no overage charge. Those tickets resume on their own after a top up. Every other reason needs a person.

Can it do anything outside the ticket?

Very little, deliberately. The bot is silent in every channel it was not invited into.

It will speak in one optional public channel, and by default only when mentioned there. In that channel it has no tools at all: it cannot escalate, cannot close anything, cannot look at another channel and cannot learn from what it reads. Anything account specific gets pointed back at a ticket. The public FAQ channel covers when that is worth turning on.

The website chat widget is locked down the same way, for a sharper reason. A visitor on your public site must never be able to make your Discord server list its channels or read a member's roles, so the widget has none of those tools. It answers from what you taught it and hands the visitor into a private Discord thread when a human is needed.

It does not message your members either. Inside a ticket it only replies, and the single DM an opener gets is the transcript link at close. When it does read a channel it reads through the opener's own permissions, so it cannot quote a staff only channel to somebody who was never meant to see it. Permissions has the full model.

What it cannot know

Adding the bot to a server absorbs nothing. It does not receive your pinned messages, your rules channel and their numbering, your channel topics, your member list, or anybody else's past tickets.

That is the middle row of the first table, and the most common cause of a disappointing first week. What your server's AI actually knows sets out what reaches it each turn, and how to train it is the fix.

One part belongs here rather than there, because it is a hard limit rather than a setup step. The AI does not learn on its own. A closed ticket becomes training only when a person picks that one ticket, and only when staff corrected the AI inside it. One the AI resolved alone is refused outright, because there is no better answer in it. Nothing is ingested in the background, ever.

What we do not build

The bottom row of the table. These are real absences, not roadmap language.

The re-crawl gap is the likeliest to bite. Nothing re-reads your site on a schedule, so the usual cause of a confidently wrong answer is a policy page that changed in March and a training job nobody re-ran.

The missing assignment is category wide rather than ours alone. No Discord ticket bot we have looked at assigns a ticket to a named person, so the queue drains through whoever feels worst about leaving it. Support team structure and spotting burnout start from that fact.

Which of these should change your decision?

Only the third group, and it is the shortest one.

If your objection sits in the top row, the product is working as intended and the refusal is doing a job you would otherwise do yourself. If it sits in the middle row, it is an evening with your five most common questions and it stops being true. If it sits in the bottom row, it is real, it will not resolve itself, and we would rather you found out here than three weeks in.

The honest scale of what the rest buys you. Across more than 180,000 tickets in this bot's lifetime, roughly half closed with no human replying at all, and the first reply lands in seconds at any hour. That is a large amount of work removed. It is also not the whole queue, and it never will be.

Every claim here is checkable: the figures at /api/stats/global, the limits at /pricing, and the machine readable version at /llm-info.