Player Support: Running Tickets Without a Helpdesk Team

Your Discord DM list has nine unread conversations in it. One is a player asking where his enchanted pickaxe went after Tuesday's crash. One is a ban appeal for a ban you did not issue and cannot find a record of. One is somebody asking how land claims work, which is answered in the pinned message he has just scrolled past. One is a purchase that went through on Friday and delivered nothing, and it has been sitting there since Friday. You are the only person who can see any of it, you answer on your phone between other things, and when you were away for a fortnight in August the queue simply stopped moving.

Nobody opens a server intending to run a support desk, and you are not going to hire one. So the goal is not good support. The goal is support that takes an hour a week, produces the same answer twice, and keeps working on the days you are not there.

Here is the order to fix it in, roughly by how much work each change gives back.

1. DM support fails three ways before you have even replied

It is tempting to treat the DM pile as a workload problem — too many messages, not enough hours. It is not. It is a routing problem, and it breaks in three specific places.

It is invisible. No other member of staff can see the conversation, so nobody can pick it up, nobody can check whether it has been answered, and nobody can see that four people have asked the same thing this week. Your moderators are not lazy; they genuinely do not know the queue exists.

It cannot be handed over. When a moderator burns out and leaves, every conversation they were holding leaves with them, along with every promise they made. There is no way to answer "did we already restore this for him?" because the only copy of that history was in somebody's private messages.

It trains players to skip your staff. This is the expensive one. The first time a player gets a result by messaging the owner directly, he has learnt the fastest route, and he tells his friends. Within a couple of months your moderators are decorative and every decision escalates to one person, which is exactly the arrangement you were trying to avoid.

Support is not a favour you do a player in a DM. It is a record, readable by somebody who is not you, that the same question got the same answer twice.

The fix is not software. It is a single visible place where requests land, plus a rule that staff answer nothing important in private.

2. Five requests make up nearly all of it, and each one wants a different process

Almost every message you get is one of these, and lumping them into a single "support" channel is why the queue feels so heavy — you are switching between an accounting question, a judicial question and a documentation question with no warning.

1. "I lost an item." A factual claim about the past, usually unverifiable, always emotive. Needs logs and a written policy. Section 3.
2. "I was banned." Not a support ticket at all. It is an appeal, it needs a separate form, a reviewer who is not the banning admin, and a decision window — the machinery covered in moderating a game server community. Routing appeals through general support guarantees they get argued rather than reviewed.
3. "I paid and did not receive." The one category with a real audit trail, and the one where slowness costs you actual money. If you sell through Tebex, commands normally fire within a minute or two of the payment clearing, and anything for an offline player queues until his next login — so most of these are a mistyped username, a purchase made on the wrong server, or a plugin that has lost its connection. Find the transaction, use Resend in the Payments panel, and answer it the same day. A player who has paid and been ignored for a week does not open a second ticket, he opens a chargeback.
4. "Somebody griefed me / said this to me." A report about another person. It must be private, the reporter's name must not travel, and it is the start of a moderation case rather than a request to be fulfilled.
5. "How do I…" A documentation failure wearing a ticket costume. Section 8.

3. "I lost an item" is the category that eats a server

It consumes admins for a structural reason: in the general case the claim is unfalsifiable, and every restore you grant raises the expected value of asking.

Start with what your logs can genuinely tell you. On Minecraft servers, CoreProtect records container transactions — /co lookup u:Player t:3d a:container will show you what came out of a chest, and /co rollback can put it back. What it does not log is the inventory a player was carrying. So "someone raided my base" is answerable and "I died in lava with my netherite kit" is not, and no amount of goodwill changes which of those the database contains. On FiveM servers the picture is different again: with ESX or QBCore-style frameworks the inventory lives in your database, so a lost item is a query with an actual answer, and your policy can afford to be more generous because your evidence is better.

The trade-off is real. Restoring keeps a regular who genuinely got robbed by your own crash, and refusing everything makes you look like you do not care when the fault was yours. But an open restore policy has no ceiling — the claims grow to fill whatever willingness you show, and you end up adjudicating stories.

Restore when the server caused the loss and you can see it in a log. Never restore for player error. A crash, a rollback to an earlier save, a plugin that ate a chest on restart — those have a timestamp, a known blast radius, and a finite list of affected players. Restore for all of them, announce it publicly, and do it without being asked, which generates far less work than forty individual tickets. Dying in lava, dropping something, getting talked out of it in a trade: not restored, ever, no exceptions, and the exception you make in month one is the policy you will be arguing about in month six.

Write that in one sentence and put it in your rules, where rules that an admin can actually apply live. A support policy that is not written down is not a policy, it is a mood.

4. Canned replies are consistency, not laziness

The objection to templates is that they feel impersonal. What they actually prevent is worse than impersonal: two moderators giving two different answers to the same question, which is what produces the escalation to you and the accusation of favouritism a week later.

Keep six to ten in a staff-only channel that any moderator can edit. Each should contain the answer, the reason for it, and what happens next. None should contain an apology that implies an exception is available — sorry, there is nothing I can do invites a negotiation, whereas we restore items when the server caused the loss, and this one is not in the crash window ends one. Personalise the first line, keep the rest fixed.

5. Your ticket system is a forum channel and a bot, not helpdesk software

Do not buy Zendesk. The cost is not the licence, it is that players will not leave Discord to file a ticket, so you end up with an empty queue and a full DM list — the original problem, now with a subscription.

Discord's forum channels do most of the job natively, and after the changes to how community servers are structured most servers already have them available. A forum channel gives you one thread per request, up to 20 tags, and the option to require a tag before somebody can post — so make the tags your five categories from section 2 and the routing happens before you read a word. Post guidelines take up to 2,000 characters, which is enough to state the restore policy and the response time in front of the person about to type. Set the auto-archive to three or seven days rather than the 24-hour default, so a thread waiting on a reply does not vanish overnight.

What a forum channel cannot do is privacy: every post is visible to everyone with access to the channel. That rules it out for reports about other players, for payment problems where a transaction ID gets pasted, and for anything involving a real name. For those, a ticket bot — Tickets, Ticket Tool, or a self-hosted equivalent — opens a private channel per ticket, lets a staff member claim it so two people do not answer at once, and writes a transcript when it closes.

Run both. Forum channel for "how do I" and lost items, because the answers are reusable and other players read them. Ticket bot for reports, payments and appeals, because those need to be private and need a transcript.

6. Publish a response time you can actually hit

Silence is not neutral. A player who has waited four days without acknowledgement does not conclude that you are busy; he concludes he has been refused, and then he escalates — into your DMs, into a public channel, and eventually into the reputation of the server itself, which is one of the things a browsing player reads into a listing.

So state the number, and make it one you will still hit in a bad week. We usually reply within two days beats both silence and the fantasy of 24/7 support. Put it in the forum post guidelines and in the bot's auto-reply, so the expectation is set before the wait begins rather than defended afterwards. If you are one person working evenings, say that too — nobody resents a stated limit, they resent an unstated one.

Pick your support window using data rather than habit. Your listing reports a busiest hour derived from readings taken every 15 minutes, and how that is produced is documented in the methodology; if your server fills at 20:00 UTC, an hour spent on tickets at 20:00 catches people while they are still online to test the fix.

7. Close the ticket, and say what closed it

Almost nobody does this, and it is why support queues rot. Unclosed threads accumulate until the channel is mostly dead conversations, at which point staff stop reading it, at which point real requests sit unanswered inside a channel that technically exists.

Every ticket ends with a message stating what was decided — including, and especially, when the answer is no. Then it closes. The auto-archive handles the housekeeping; a Solved tag handles the visible part. The transcript is the thing DMs never gave you: six months later you can check whether this is the third netherite pickaxe this player has lost.

Watch one number: open tickets older than your stated response time. If that count is growing week on week, either the promise is wrong or one category has outgrown the queue and needs documenting instead of answering.

8. Half of it was never a support problem

Tag your tickets by category for a fortnight and count them. The "how do I" pile is not a support workload, it is a list of things your server failed to explain, and every entry on it is cheaper to fix once than to answer forty times. The top two go into the spawn signage, the forum post guidelines and the first line of your description on whichever directory you are listed in — because a player who understood the server before joining never files the ticket at all.

That is the actual test of a support system. Not how fast you reply, but whether the queue gets shorter for reasons other than you giving up on it.