Skip to main content
Guides
GuidesTicketsSupport

Setting Up a Discord Ticket System: What to Settle Before the First Click

A ticket system is quick to set up and often unusable afterwards. The decisions that actually matter are the ones you make beforehand.

Published on by AlphaCloud4 min read

A ticket system solves one concrete problem: support no longer happens in public channels, where everybody reads along and nobody is responsible, but in a private channel between the person with the problem and your team.

The technical part takes ten minutes. The reason ticket systems still often end in chaos comes down to four decisions best made in advance.

Decision 1: How many categories

The most common mistake is splitting too finely. A server starts with eight categories because they all sound sensible somehow: General, Technical, Application, Complaint, Partnership, Bug, Purchase, Other.

The result is predictable. Members pick the wrong category, your team has to move tickets around, and six of the eight never receive anything anyway.

Start with two or three. A good split follows who is responsible, not what it is about:

  • General support for everything your support team answers
  • Applications for everything team leadership sees
  • Reports for everything moderation sees

If a category regularly overflows after three months, split it. The other direction, retiring a dead category, is more unpleasant, because you then have to move tickets.

Decision 2: What you ask when opening

Most systems can show a small form before the ticket is created. That saves the first round of follow-up questions but adds friction.

The rule of thumb: only ask for what your team needs to start. Everything else comes up in conversation.

Good:

What is this about? (required, paragraph) What have you already tried? (optional, paragraph)

Bad:

Name, age, time, operating system, Discord ID, read the rules (yes/no), screenshot link, urgency from 1 to 5

Discord allows at most five fields per form anyway. Use two of them.

Decision 3: Who sees which ticket

This is the point you regret long-term if you get it wrong.

A ticket system assigns channel permissions per category. So the question is not "who is on the team" but "who may read applications". If your support team has access to the applications category, fifteen people read along when somebody applies. That is rarely intended.

Set the roles per category, not globally. In AlphaCloud that is the support roles field in every ticket category.

Decision 4: What happens to closed tickets

A server with active support quickly produces hundreds of ticket channels. There are three usual approaches:

Approach Upside Downside
Channel stays, moved to an archive category Everything readable Discord allows at most 500 channels per server
Channel is deleted Clean The history is gone
Channel is deleted, a transcript is created first Both Needs a system that can do it

The third is the right one as soon as your support runs regularly. A transcript is a searchable copy of the conversation that is still there long after the channel is gone. You need it at the latest during the first argument about what was supposedly promised in a ticket.

AlphaCloud stores transcripts on their own site, attachments included. What matters is that attachments are saved on close, because Discord's image links stop working once the channel is deleted.

The setup itself

Once the four points are settled, the rest is mechanics:

  1. Create a Discord category for the ticket channels to appear in
  2. Create the categories in the bot and set the support roles
  3. Optionally one or two questions per category
  4. Post a panel into a channel for members to open from
  5. Set a log channel

Afterwards, definitely open a ticket yourself and go through it once. That is where you notice that the team cannot see the new category at all, or that the welcome message is still the placeholder text.

Two things worth adding later

Ratings. After closing, the system can ask for a rating. That is less useful for statistics than for the one case where somebody gives one star and writes why. You never get that feedback otherwise.

Automatic closing. Tickets where nobody has written for days clog the overview. A timer that closes after 48 hours of silence, asking once beforehand, keeps the list clean without anybody having to tidy up.

What a ticket system does not solve

It does not make support faster. It only makes it findable, owned and readable afterwards.

If nobody answers, no system helps. What helps: a notification to the team when a ticket opens, and an honest note in the panel about how long it currently takes. Both are considerably less work than apologising for silence afterwards.

More articles