How to set up a Discord ticket system

Four settings decide whether a ticket system survives a real staff team, and nobody configures them on day one: a form before the channel opens, a route to the right staff, a claim so two people do not answer at once, and a limit so one member cannot open forty. Configure those four and the rest is decoration.

If you have not built a panel before, how to create a Discord ticket system covers the channel structure and the first panel. This page picks up where that leaves off, at the point where more than two people are answering.

Before you start: you need Manage Server. The bot needs Manage Channels and Manage Messages, and it needs to be able to write permission overwrites for every role a ticket grants access to.

1. Decide the ticket types before you touch the panel

Not categories in a menu — routes. Each type answers three questions, and if it cannot answer all three it is not a separate type.

A general community usually needs three: General help, Report a member, Appeal a punishment. Add a fourth only when a real queue exists for it.

The appeal route is the one that justifies the whole exercise. It needs a different staff role from reports, a different category, and a rule that the applicant cannot close their own appeal. Building appeals as “just another option” is how a system stops being trusted.

2. Build the channel structure

The panel needs somewhere to put tickets, and getting this wrong is the most common reason a system fails silently.

Three things, in this order:

• A Tickets category, with @everyone denied View Channel. Every ticket channel created inside inherits that denial, which is what keeps tickets private without per-channel work.
• A #support channel outside the category, visible to everyone. This is where the panel lives — it has to be reachable by people who cannot yet see any ticket.
• A Ticket Archive category, staff-only. Where closed tickets go matters more than it sounds, and step 9 explains why.

Then grant your support role View Channel and Send Messages on the Tickets category, not on individual tickets. Per-ticket permissions are managed by the bot; the category is what makes staff able to see tickets at all.

The failure this prevents. Granting the support role permissions on the panel channel but not on the ticket category produces a system where members can open tickets that no staff member can see. Nothing errors. Nobody notices until a member complains a second time about being ignored.

3. Put a form in front of the ticket

The single highest-value setting in a ticket system, and the one most often skipped.

Without a form, every ticket starts with three round trips: what happened, when, and can you show me. Each round trip is hours of elapsed time because the two people are in different timezones. A form collects all of it before the channel exists.

Discord’s modal limit is five fields, so five is what you get and five is enough. A report form that works:

1. Who are you reporting? (a user picker)
2. Which rule was broken? (a dropdown of your actual rules)
3. When did it happen? (short text)
4. What happened? (paragraph)
5. Evidence link (short text)

Vetox supports eight field types — short text, paragraph, a dropdown of your own choices, and user, role, channel and mentionable pickers, plus file upload — with up to five per option, and per-field validation on length and selection count. Forms are part of the Basic plan.

Two rules for writing them. Make everything required unless it genuinely is not, because an optional field is a field nobody fills in. And use pickers rather than free text wherever the answer is a user, a role or a channel, because a typed username is ambiguous and a picked one is not.

4. Route each type to the staff who own it

A ticket everyone can see is a ticket nobody owns.

Set the support role per option, not once for the whole system. Reports go to moderators. Appeals go to a senior role that was not involved in the original punishment. Purchases go to whoever handles purchases.

Vetox layers this: a server-wide support role list is added to every ticket, and each panel option adds its own on top. So a base moderator role sees everything while an appeals role is added only to appeals. Each option also carries its own channel category and a twelve-flag permission matrix for the ticket opener and for staff — view, send, read history, attach, embed, react, external emoji, external stickers, mention everyone, manage messages, manage channel, create invite — each set to allow, deny or inherit.

Use the deny side. An appeals ticket where the applicant cannot delete their own messages is a better record than one where they can.

5. Turn on claiming

Two staff answering the same ticket is the most common failure in a young support team, and it wastes the more experienced person’s time every single occurrence.

Claiming assigns the ticket to one person. Vetox offers four modes and the differences matter:

Start with Enabled. It gives you ownership without cutting off a second opinion, which a new team needs. Move to read-only once the team is experienced enough that a second voice in a ticket is noise rather than help.

Private is for appeals and anything involving one staff member discussing another.

6. Set the limits before you need them

Three numbers, and each of them exists because somebody once did the thing it prevents.

Open tickets per member. One is the right answer for most servers, and it is Vetox’s free-tier limit; paid tiers raise it to five. A member with five open tickets is not five problems, it is one problem restated.

A cooldown between tickets. Stops the open-close-open loop. Vetox accepts anything from zero up to an hour, with a floor of ten seconds on any non-zero value.

A blocked-user list. For the member who uses tickets to harass staff. Vetox allows 100 blocked users on the free tier and 500 on paid, and each entry takes an expiry — anything from a minute to a year — or none for permanent. Prefer a timed block: a permanent one is a decision nobody revisits.

There is also a server-wide ceiling on concurrent open tickets, which is a safety valve rather than a policy. Vetox caps it at 200 on the free tier and removes the ceiling on any paid plan.

7. Add priority and escalation once you have a queue

Skip this on day one. Add it when tickets start waiting.

Priority sorts the queue. Vetox offers none, low, medium, high and urgent, settable by staff inside the ticket, plus up to ten automatic rules that read a form field and set a priority from its value — so a report whose “rule broken” field says cheating can arrive already marked urgent.

Escalation hands a ticket to a different panel with different staff. Vetox binds escalation targets per panel, up to 25, and exposes /ticket escalate with autocomplete over them. The useful shape is a first-line panel that can escalate to a senior one, so juniors have a defined action other than pinging someone.

Both are part of the Basic plan.

8. Decide whether you have support hours

Most servers do not, and pretending otherwise is worse than saying nothing. But a storefront or a team with a real rota should say so, because an unanswered ticket at 2am is a bad experience created by a missing sentence.

Vetox models this as a weekly schedule in your own timezone with four states — open, reduced, emergency and closed — up to fourteen periods, a message per state, an option to block ticket creation outside hours, and bypass roles for people who should always get through. It is part of the Max plan.

Whatever your tooling, the minimum is a line in the panel embed saying when someone will look. It costs nothing and it removes most of the follow-up messages.

9. Turn transcripts on, and understand why

Transcripts are usually sold as convenience. The real argument is retention.

Discord’s own record is finite: “All audit log entries are stored for 45 days.” It also does not cover message content at all. So a deleted ticket channel is gone, and a dispute about what was said in it three months ago has nothing behind it.

A transcript is a written record of the conversation that outlives both the channel and Discord’s window. Turn it on before you need it, because you cannot generate one retrospectively.

Two practical points. Check what your bot’s transcript actually captures — Vetox collects up to 2000 messages per ticket, up to 2000 characters each. And check how transcript links are secured: Vetox serves them through a signed link and lets a server invalidate every link it has ever issued in one action, which is the control you want the day a link ends up somewhere it should not be.

10. Write the closing message

When a ticket closes, the member should get a short message saying it is closed and how to reopen or escalate. Without one, closing reads as being dismissed — the member cannot tell the difference between “resolved” and “ignored”, and the next thing they do is open another ticket or complain publicly.

Two sentences is enough: what was resolved, and what to do if it was not. It is the difference between a support system that feels like support and one that feels like a queue.

11. Measure it, or you are guessing

Three numbers tell you whether the system works, and all three come from the ticket data rather than from anyone’s impression.

• First response time. The one members feel. Everything else is secondary.
• Resolution time. Whether tickets are being answered or merely acknowledged.
• Satisfaction. A one-to-five rating on close, with an optional comment.

Vetox reports all three on a ticket overview page with a selectable window of 7, 14, 30, 60 or 90 days, plus a per-staff breakdown of tickets handled, average response, average resolution and average rating. Ratings and the staff performance breakdown are part of the Basic plan; a formal SLA — a first-response target from 1 to 1440 minutes with a warning channel when it is missed — is part of Max.

Look at the staff breakdown monthly, and look at it for the person who is quietly carrying the queue. Uneven load is what burns out a volunteer team, and it is invisible without this table.

12. Set staff notifications so the right people are interrupted

An unread ticket and an unnoticed ticket are the same thing to the member waiting.

Vetox makes this a per-staff-member preference rather than a server setting, which is the right shape — five switches, defaulting to on for ticket created, on for escalated, on for an SLA breach, and off for closed and rated. Staff edit their own with /ticket notifications.

Encourage everyone to leave “created” on and turn “closed” off. Notifying the whole team that a ticket someone else handled is finished is how people mute the bot entirely.

13. Test the whole path, from a normal account

Configuration that has only ever been tested by an administrator is untested.

1. Open a ticket from a second account with no staff roles. Confirm the form appears and that required fields are enforced.
2. Confirm the right staff role was added, and that nobody else can see the channel.
3. Claim it from a staff account. Confirm the mode from step 5 behaves as you set it.
4. Try to open a second ticket from the same member. Confirm the per-user limit refuses it.
5. Close it. Confirm the transcript is generated and the rating prompt appears.
6. Check the log channel received the open and the close.

Step 4 is the one people skip, and the per-user limit is the setting that most often turns out to be higher than intended.

Step 2 is the one that fails quietly. If the ticket opens and staff cannot see or act in it, when tickets stop opening or staff cannot reach them puts role hierarchy first — the cause that produces no error, no log entry and no symptom beyond a member waiting.

Where the tiers sit

Worth knowing before you design something you cannot run. On Vetox, the free tier gives you 3 panels of 3 options each, 200 concurrent tickets, one open ticket per member and 100 blocked users — a working help desk for a small community, with the whole /ticket command set and its 14 subcommands.

Basic is where the operational layer arrives: forms, ratings, inactivity auto-close, priority, escalation, per-ticket custom embeds, DM transcripts, closed-ticket archiving and the staff statistics, plus 10 panels of 15 options and five open tickets per member. Max adds support hours, the SLA and staff threads, and raises panels to 25.

Six starter templates ship with it — gaming, e-commerce, community, tech support, bot support and development — which is the fastest way to see a sensible configuration before you build your own.

Common questions

Channels or threads? Channels for anything that needs a durable record or unusual permissions. Threads for high-volume, low-stakes questions where the archive matters less. Vetox supports both per panel.

How long before a ticket auto-closes? Long enough that a member in another timezone can reply. Vetox accepts anything from 6 hours to 7 days, and 48 to 72 hours with a warning first is the range that annoys the fewest people. It is part of the Basic plan.

Why does auto-close matter if nobody is complaining? Because most tickets are never closed by anyone — the member gets their answer and leaves, and the channel stays. A Discord server has a hard ceiling of 500 channels, and a busy support server reaches it faster than expected. Auto-close is what stops a working ticket system from filling the server it runs in.

Why can the bot not create the ticket channel? Manage Channels, or a category the bot cannot write to. If the panel button does nothing at all, start with why your bot is not responding; if the channel opens but the staff role is not added, it is the role permissions, and which permissions a bot actually needs has the list.

Should members be able to close their own tickets? Yes for general help — it clears the queue. No for appeals and reports, where closing is a decision rather than a tidy-up.