Guide · September 1, 2026 · 3 min read
Ticket-based support instead of private messages
As long as support runs through moderators' private messages, it depends on the availability of the one person you happen to know. Nothing is recorded, nothing is handed over, and the most visible member receives everything. A ticket system moves that work into a shared space.
Contents
What a ticket changes
A ticket is a private channel, opened on request, visible to the person and to the team. Three immediate consequences.
The request is visible to the whole team. Any available moderator can take it, instead of waiting for the one it was addressed to to come back.
It is traceable. What was said, promised and decided stays readable — including six months later, when the same person comes back about the same thing.
It can be handed over. A moderator who goes on holiday, or leaves the team, does not leave behind a dozen conversations nobody can pick up.
The opening panel
A ticket is opened from a pinned message in a dedicated channel — a button, or a dropdown. The difference between the two is not cosmetic: the dropdown lets you offer several topics, and the topic changes everything that follows.
Four topics cover most servers: a general question, a report about a member, a technical problem, an appeal after a penalty. Each can have its own welcome message, its own assigned team, and its own channel category.
The “appeal after a penalty” topic deserves separate handling: the person opening it is in conflict with a member of the team. The ticket must not land with whoever made the disputed decision.
The ticket's welcome message
It is read by someone waiting for an answer. Three pieces of information, no more:
- What is needed from them to move forward (screenshots, the username involved, the date).
- The usual response time — even a rough one.
- The fact that the conversation is visible to the team, not to other members.
Claiming the ticket
Without a named owner, a ticket ends up in one of two symmetrical situations: three moderators answer at once and contradict each other, or nobody answers because each assumes somebody else is on it.
The claim button settles both: a moderator declares themselves responsible, their name shows, and the others know it is handled. It also produces the one useful statistic in the whole system — how many tickets each person has handled, which beats a vague impression for judging the real load.
Closing cleanly
Closure must produce two things. A transcript of the channel, archived in a team-only channel: that is what remains once the channel is gone, and it is indispensable if the decision is disputed.
And a notification to the person, with the option to reopen if the answer does not suit. A ticket closed without a word feels like a slammed door, even when the problem was solved.
Deleting the channel can be deferred by a few hours: that leaves time to retrieve a forgotten detail, without letting dozens of closed channels pile up.
The classic mistakes
- One topic for everything. Requests have neither the same urgency nor the same recipient; mixing them puts a serious report behind a question about role colours.
- Too many topics. Beyond five, people pick at random and the sorting stops being useful.
- Not limiting open tickets per person. One at a time stops a disgruntled member from opening twelve.
- Leaving tickets open indefinitely. An automatic nudge after a few silent days, then a closure, keeps the list usable.
- Forgetting the transcript. You notice on exactly the day you need it.
Frequently asked questions
Should tickets be anonymous?
No: the team needs to know who it is answering. An anonymous report belongs to a different mechanism, with its own rules.
How many moderators does it take to run tickets?
Two are enough on a small server, provided you announce an honest response time. What discourages people is not the wait: it is waiting without knowing how long.
Can somebody be added to an open ticket?
Yes, and it is often necessary — a witness, a lead, or the person a report is about. Removal must be possible too.
What about abusive tickets?
Handle them like everything else: closure with a reason, and a warning if it repeats. Blocking a specific person from opening tickets stays the last resort.
Read next : Warnings and penalties, Logging, Team rota.