Discord Ticket Categories: Naming, Routing and Staff Roles

Almost every ticket setup starts the same way. Someone makes one panel with one button that says "Open a ticket", it works, and then a month later half the tickets are questions the AI could have answered and the other half are billing problems being read by fourteen moderators who cannot help with them. The fix is not a bigger panel. It is deciding what a category is for before you add the third one.

What is a ticket category on a Discord bot?

It is one choice on your panel: an option in a dropdown, or its own button. To a member it looks like a label. Underneath, on our bot, it carries four settings that each override the panel's default.

Every one of those four is tri-state. Leave it alone and the category inherits the panel; set it and the category wins. That matters more than it sounds, because it means a well-built panel usually has one category with everything set and three that only override the one thing that differs.

There is one more thing a category does that has nothing to do with configuration, and it is the part nobody documents. On a ticket where the AI is enabled, the bot prepends a single context line to the member's first message before the model ever sees it, and that line is [Ticket #1284 · billing · opener: Alice]. Three facts: the number, the category name, and who opened it. The description is not in there. So the word you type in the name box is genuinely read by the thing answering your members, and "Support 2" tells it nothing at all.

How many ticket categories should you have?

Fewer than the plan allows. The plan cap is rarely what bites.

The honest test for whether a category should exist is whether it changes who answers, where it lands, or whether the AI is involved. If a new category would change none of those three, it is a label, and it belongs in the first question of the form rather than on the panel. Form questions are the right home for anything that is really a detail about the ticket.

That last row is not a joke and it is the only one that costs you anything. A panel with nine categories does not produce nine well-sorted queues. It produces a lot of tickets in whichever one is at the top of the list.

More categories, or more panels?

This is the question people get wrong, and it has a mechanical answer rather than an aesthetic one.

A ticket can be transferred between categories on the same panel. It cannot be transferred to a different panel. So the moment you split one audience across two panels, a ticket that lands in the wrong one is stuck there. Your only options are to close it and ask the member to open another, or to answer it in the wrong place.

Use a second panel when the audience or the channel differs: a staff-only panel in a private channel, an applications panel that lives in a different part of the server, a partner panel only a role can see. Use categories for every split inside one audience. The rule of thumb: if the two groups of people would ever both be looking at the same panel post, they belong on one panel.

What should you name a ticket category?

Name it after what the member has, not after which team you have. Members do not know your org chart, and every name that describes your internal structure quietly asks them to guess.

Two mechanical details that change how the name behaves.

In dropdown mode you get a second line, on buttons you do not. The panel renders either one dropdown of options, each with the name and a 100-character description underneath, or one grey button per category, five to a row, showing name and emoji only. If you are on buttons, the description you carefully wrote is never displayed to anybody, so the name has to carry all of it.

The name flows into the channel name if your template asks for it. If your naming template includes the category, then ticket-1284 becomes something like billing-1284, and a staff member can see what a ticket is about from the channel list without opening it. That is worth more on a busy server than it sounds, and it is covered along with the rest of the setup in setting up your first ticket bot.

How do you send each category to the right staff?

Every category can name one responsible staff role. On our bot that role is not a notification setting, it is a permission.

When a channel-mode ticket opens, the bot writes the channel's permissions from scratch: everyone is denied, the opener is allowed, any staff role you marked See others is allowed, and the category's responsible role is allowed. If the category does not name one, the panel's role is used. If neither names one, the list ends there.

If you have ever had "tickets nobody answers" on one specific button, that is almost always the reason.

The ping is a separate switch with its own inherit state, which is the combination worth knowing about:

The same role is used when the AI decides to hand a ticket over. Escalation pings the category's role if it has one and the panel's role otherwise, which means a per-category role gets you correct routing on both the automatic path and the manual one, from one field. If ticket permissions in general are what you are stuck on, what a ticket bot needs to work covers the server side of it.

Should the AI answer in every category?

No, and the per-category switch exists precisely because the honest answer is no.

The AI is worth having on any queue where the answer already exists somewhere: general questions, how-do-I, where-is-this, anything your staff have already taught it. Across this bot's lifetime, roughly half of more than 180,000 tickets have been resolved without a human, and those are overwhelmingly that kind of ticket.

It is the wrong first responder on queues where being answered by software is itself the problem. A ban appeal, a report about another member, a safeguarding issue. Not because it would answer badly, but because the member needs to know a person is reading it.

A ticket that starts with the AI on does not stay that way regardless. It steps aside the moment a staff member replies, when it is claimed, or when it escalates itself, so the switch controls the opening rather than the whole conversation. What it does control absolutely is the first impression, and on an appeal that is the entire thing.

Where do the ticket channels actually go?

By default, into whatever Discord category the panel points at. Each ticket category can override that with its own target, which is how you get billing tickets landing in a private area your moderators cannot browse, while general tickets land in the open staff area.

Two rules the bot enforces so this cannot half-work:

• The target type has to match the panel's mode. Channel-mode panels need a Discord category, thread-mode panels need a text channel. A mismatch is refused at save time rather than at ticket-open time, because the second one fails in front of a member.
• The target has to be in this server. An id belonging to another server the bot happens to share is rejected outright.

Separating targets also spreads you across Discord's 50-channel-per-category limit instead of piling every open ticket into one. That limit, and what large servers do about it, is covered in running a ticket bot at scale.

Can each category ask its own questions?

Yes. The form is per category, not per panel, so "Report a member" can ask who and when while "General" asks nothing at all. That is a Premium feature and it caps at five fields per category, because Discord allows five.

The full argument for which questions earn their place lives in what to ask before a ticket opens. The one thing worth repeating here is the link between the two features: the answers are handed to the AI as the ticket's first message, so a category with good questions and the AI enabled gets a real attempt at an answer instead of "hi, how can I help".

What happens when someone picks the wrong category?

They will. Design for it rather than trying to prevent it.

/ticket transfer needs the Transfer staff permission or Manage Server, and here is exactly what moves and what does not:

Now the two honest gaps, because they are the ones that surprise people.

A transfer does not rewrite the channel's permissions. Those were written when the ticket was created. Moving it into a category whose responsible role is different does not grant that role access, so the team you just transferred it to may not be able to see it. There are two clean fixes: give the roles that handle transfers the See others permission, or set permissions on the parent Discord categories themselves so that moving the channel moves its access with it.

A claimed ticket is not physically moved. A claimed ticket lives in its claimer's own working area, and dragging it out mid-conversation would be worse than leaving it. The transfer is recorded and the ticket moves for real when it is unclaimed.

Can you rename or delete a category later?

Both, and they do different things to your history. This is the part worth reading twice.

A rename rewrites the past. The new name is copied onto every ticket ever opened in that category, open and closed alike. Rename "Support" to "General Help" and a ticket from March now reports General Help. That is correct when you are fixing a name and wrong when you are changing a meaning, because those March tickets were not about the new thing.

A delete freezes it. The name stays written on the tickets that used it, the link to the category does not. So if the meaning is genuinely changing, add the new category and delete the old one instead of renaming, and your history stays truthful.

Deleting asks you what to do with tickets still open in it, and the default is to refuse:

There is one more case that looks like data loss and is not. If you downgrade a plan, categories beyond the new limit are hidden, not deleted. They stop rendering on the published panel and they come back the moment the plan does. It is worth knowing before you look at a panel that used to have ten options and count seven.

How do you know your categories are right?

Categories are one of the few support settings with an honest feedback signal, so use it instead of guessing.

The tooling for the first two is split, which is worth knowing before you go looking. In Discord, /ticket search filters by panel, status, priority and person, but not by category. The dashboard's ticket list does filter by category, so that is where a per-category count comes from. Support analytics covers the rest of what is measurable.

Changing your categories does not update a panel that is already posted on its own. Publish again, or the post keeps showing the old list.

When more categories is the wrong answer

Sometimes the queue is not badly sorted, it is badly sized, and no amount of routing fixes that.

If the same question arrives in every category, the answer is a public FAQ channel or better training, not a new button. If tickets sit unread for days, the answer is working hours so members know when to expect a reply, and auto-close so the list stays readable. If the total volume is the problem, reducing ticket volume is a different project entirely and a more valuable one.

Categories decide who answers. They do not decide how many people ask.

Start with three

If you are building this today: make one panel, give it three categories, set a responsible role on each, turn the AI off on whichever one is about people rather than problems, and publish. Watch the transfers for two weeks and let those tell you what the fourth category should be.

The instinct to design the whole tree up front is the thing to resist. Every category you add before you have evidence is a guess about how strangers read your server, and the transfer log is a much better source than the guess.