Ticket routing for RP servers: stop sending every issue to every staff member

Most RP Discords start with one button: Open Ticket. It works for the first 20 members. Then the server grows and the queue becomes a pile of unrelated work: whitelist questions, ban appeals, bug reports, comp requests, staff complaints, faction drama, payment issues, and player reports.

Everyone can see it. Everyone assumes someone else will handle it. The player waits. Staff feel busy but the queue does not move. That is not a staffing problem first. It is a routing problem.

Start with route names that match player intent, not staff department names.

1. Whitelist help. Application status, missing info, interview scheduling, resubmission questions.
2. Bug report. Repro steps, screenshots, location, character, time, framework context.
3. Comp request. Evidence, loss estimate, staff reviewer, approved/denied reason.
4. Player report. Incident time, involved players, clips, rule category, urgency.
5. Ban appeal. Ban ID, staff member if known, appeal statement, prior history.
6. Faction issue. Roster, rank, leadership conflict, faction-specific evidence.
7. Staff complaint. Private route with limited visibility and owner-level escalation.
8. Account/access. Discord role, whitelist role, connection, queue, or identity linking problem.

If you route only by "support", staff must classify every issue manually. That classification work is exactly what the ticket system should remove.

Every route needs a written spec. Without it, a ticket category is just a folder.

• Owner group. Who is responsible for first response?
• Required evidence. What must the player include before staff can decide?
• First-response SLA. How quickly should staff acknowledge it?
• Resolution SLA. How quickly should normal cases close?
• Escalation rule. When does it move to senior staff or owner?
• Close template. What does a clean final answer include?

A good route spec reduces emotional load. Staff do not have to invent policy while a frustrated player is typing in real time.

Not every ticket deserves the same speed. The matrix below is a sane starting point:

The exact hours can change. What cannot change is the presence of a promise. Without a promise, nobody can tell when support is failing.

Every repeated ticket deserves a response template. Not because staff should sound robotic, but because inconsistent answers create politics.

A comp denial should explain missing evidence. A ban appeal denial should name the rule and the next appeal date. A whitelist resubmission should identify the weak criterion. A bug report close should state whether it was reproduced, logged, or rejected.

If two staff members would answer the same ticket differently, the problem is not tone. It is missing policy.

KeepGrid includes ticket routing, incident reports, and ban appeal flow tools because templates are where support quality becomes repeatable.

Do not track total tickets as a success metric. More tickets can mean growth, confusion, bugs, or poor docs. Track the health of the queue instead:

• Median ticket age. Your best early warning for staff overload.
• Oldest open ticket. The ticket most likely to become public frustration.
• Reopen rate. High reopen means answers are unclear or policy is unstable.
• Route mix. If whitelist help spikes, onboarding docs may be weak. If comp spikes, a gameplay system may be breaking.
• Escalation count. Too many escalations means frontline staff lack authority or policy.

Review these weekly. A ticket system that is not reviewed becomes a slow inbox with better branding.

Split a route only when it changes the owner, evidence, SLA, or decision policy. Do not split because the channel list looks impressive.

Good split: ban appeals and staff complaints. Different privacy, different authority, different escalation.

Bad split: "General Help 1", "General Help 2", and "General Help 3". Same policy, more confusion.

The best route map is small enough for players to choose correctly and specific enough for staff to own confidently.

If you already have tickets, run the free Ops Audit and look for queue age, routing gaps, and staff flow issues. If you are building from scratch, Launch OS creates the route map, docs, channels, roles, and pinned workflows as one system instead of a pile of buttons.