Minecraft Discord Ticket Bot: Store, Bans and Join Problems

A Minecraft support queue has a particular shape. It is repetitive, three or four questions account for most of it, and nearly all of it is about something that happened somewhere the person answering cannot see from Discord. That last part is what to design around, and it is the part most setup guides skip.

What a Discord ticket bot can see about your Minecraft server

Short answer: nothing. A Discord ticket bot is a Discord application. It can read the ticket in front of it and whatever your staff have taught it, and that is the whole list. No console, no plugin bridge, no store connection, no punishment history.

The gap that matters most is identity. Discord knows who is typing. Your server knows who logged in. Nothing joins those two facts together unless you installed something that joins them, so the bot cannot confirm that the person in the ticket is the account they say they are, and neither can your moderator without asking.

There is one narrow exception, and it is the only purchase fact a ticket can settle without a human. When a question genuinely depends on someone's rank or permission level, our AI can read the Discord roles that person holds, strongest first. If your web store or your linking plugin already grants a Discord role on purchase, the AI sees that role and answers accordingly.

Be precise about what that proves. It proves your store believed the purchase went through. It does not prove the rank applied in game, and it says nothing about a player with no linked role. Treat it as a shortcut on the easy cases, never as verification.

Which Minecraft tickets an AI can close on its own

The useful sort is not by topic. It is by whether answering the ticket requires somebody to look something up.

If answering means opening the store dashboard, the ban list or the block log, an AI running in Discord cannot do it. If answering means somebody wrote it down once, it should not be reaching a human twice.

That split is why routing here is deterministic rather than clever. The category button a member presses decides whether the AI engages at all, you set that per category, and the AI never moves a ticket somewhere else on its own.

Across the bot's lifetime, roughly half of all tickets have been resolved by the AI with nobody stepping in. Your own share depends on how much of your queue is the same question asked again, which your own ticket history already tells you.

The store ticket, and the half of it you can automate

"I bought a rank and it did not arrive" is the store ticket most Minecraft networks know best, and it is really two tickets wearing one costume.

The delivery half is documentation. Which server do you log into for it to apply, does it need a relog, how long does it normally take, what happens if the username was typed wrong at checkout, does a Bedrock account buy on the same store as a Java one, is the rank per server or across the network. Those answers do not change from week to week. Teach them once, in your own words, and the AI closes most of these before a moderator opens Discord.

The transaction half is a record. Did the payment clear, was it refunded, was it a chargeback. That lives in your web store, usually Tebex or something like it, and nothing in Discord can see it.

Vagueness is safer than it sounds here. Our AI is forbidden from inventing a fact, a price, a policy or an availability, so a question you never covered comes back as "I do not have that" rather than as a made-up delivery time. That is the correct failure, and it is the argument for spending one afternoon on the store answers rather than none.

What an appeal or a griefing report has to ask for

Both are moderation workflows arriving through the support door, and our guide for gaming servers covers how to handle them once they land. The Minecraft-specific part is the intake, because the fields are things nobody can look up later.

The time field earns its slot. A griefing report that sits for a week can pass the point where the fix still exists, which makes a slow queue expensive in a way a slow queue on a support desk usually is not.

Screenshots are how most of this evidence actually arrives, and there is one thing to know about them: the AI genuinely reads the image, but your archive keeps a link to the file on Discord rather than a copy, and those links expire. If a screenshot is evidence you will need in three months, save it somewhere of your own while the ticket is still open.

The join ticket is the one to teach first

If you only ever teach the bot one thing, teach it why people cannot connect.

It arrives more often than anything else on most Minecraft servers, it requires no judgement at all, and the answer changes about once a year. Version mismatches, an address typed with the wrong port, a Bedrock player trying the Java address, a modpack that needs updating, a whitelist that was never applied, a launcher that has not been restarted since the update.

Write each one as a plain answer with the actual steps, teach it, and the whole category stops reaching your staff.

The same habit covers your update days. When something breaks and you know the workaround, teach it the same afternoon. Every ticket about it after that answers itself, in seconds, instead of waiting for whoever is awake.

What to capture before the ticket opens

Three facts turn most Minecraft tickets from a conversation into an answer: who they are in game, which server they were on, and when.

A form at ticket open is the reliable way to collect them. It is a pop-up in front of the ticket, it holds five fields, which is Discord's cap rather than ours, and the ticket channel is only created once it is submitted. Our guide to ticket forms covers how to spend those five slots without making it feel like paperwork.

Forms are a paid feature here. On the free plan the same job is done less reliably by your panel description and your category names, which is worth doing anyway: a member who reads "include your in-game name" before clicking usually types it.

One related trap. Your ticket channels can be named after the member, and that name comes from their Discord account, never from their Minecraft one. A channel called ticket-xx-shadow-xx tells your staff nothing about who is standing in the world, which is another reason the in-game name belongs in the ticket body. Channel naming covers what the template can and cannot do.

If your network runs several servers behind one Discord, make the server a category rather than a form field wherever you can. A button labelled Skyblock routes to the staff who run Skyblock, and the ticket arrives already sorted.

Where a ticket bot is the wrong tool

The last one deserves a sentence, because it is a mistake worth catching early. Closing a ticket deletes the channel and leaves a transcript, kept 90 days on the free plan and considerably longer on paid, and the answers a member typed into the form expire on that same clock. That is an archive, not a punishment history. Keep the record in the plugin that issued the punishment.

If what you actually need is rank syncing, a console bridge or a whitelist command, that is a plugin or a linking bot, and this sits beside it rather than replacing it. The same boundary applies to communities built on a platform rather than a server, which we wrote about separately for Roblox.

What it costs to try

The free plan runs one panel with five categories, one open ticket per member at a time, and 90 days of transcripts, with the AI included rather than held back as the upsell. Publishing your first panel then starts 14 days of Premium automatically, with no payment method at any point and nothing to cancel. That is when forms, working hours and smart inactivity handling switch on, so you can find out on a busy week whether the intake fields are worth paying for. It is one per server, permanently.