Discord Bug Report Tickets: The First Report and the Fiftieth

A bug never arrives once. The first member to hit it opens a ticket, and so do the next forty, each one sure they are the first. The first report is real work: somebody has to read it, reproduce it and decide whether it is a bug at all. Every report after that is a question you already know the answer to.

A Discord ticket bot is built for the first kind. It opens a private room per report and puts it in front of the right staff. It has no idea that ticket 212 and ticket 240 describe the same crash, so the second kind is yours to design.

How do you set up bug report tickets on Discord?

With a Bug report category of its own, a short form, and the staff role that actually reads bug reports. Everything here is free on every plan except the form.

In the dashboard, the category's Advanced tab holds the staff role, the AI switch, the starting level and the ping on open. A category of its own is what lets you treat bugs differently from billing: a different form, a different staff role, and a list of bug tickets you can pull up later.

On the free plan there is no form, so the opening message carries the ask. It is written per panel, not per category, so on a shared panel keep it general: what happened, what you expected, and a screenshot. The welcome message covers what it can hold.

What should a bug report form ask?

The four things a developer asks for and a member never volunteers. A form holds five questions per category at most, which is Discord's cap, and a label has 45 characters to work with. Spend the slots like this:

A form takes text only, so ask for the screenshot or recording in the opening message. Nothing checks an answer's format, so "idk" passes a required field. And a long answer stops at 1,000 characters, enough for steps and not for a pasted log. Ticket form questions goes through every cap.

A log belongs in the ticket as a file. If the AI is on, it reads images the reporter attaches (PNG, JPEG, WebP or GIF, up to 5 MB each) and plain text files up to 64 KB, so a short log saved as text is read with the report. It does not watch video. The transcript keeps a link to an attachment, not the file, so save any screenshot your developers will need while the ticket is open. Screenshots in tickets covers why.

Who answers the first report of a bug?

A person, every time. An AI cannot reproduce a crash, look inside your game or app, or decide that something is a bug rather than a design choice. What it can do is hand the report over in better shape.

With the AI on in the category, it reads the form answers and the screenshot. For a bug it has nothing on, it says so and offers to bring in the team. When the member accepts, it hands the ticket over with a short summary and a priority, and pings the category's staff role. It grades by what waiting would cost, never by how upset the reporter sounds:

A rule you teach wins over its own judgement, so "anything that deletes a save file is always urgent" holds. Staff can change the level with /ticket priority. Priority is a sort order, though: it moves the ticket up the dashboard's priority list and pings nobody. Ticket priority covers the rules.

With the AI off, the ticket opens straight to your staff. Turn on the ping on open for the category: it is off by default, and without it a new report waits until somebody looks. Staff pings covers why a ping can fail to notify.

How do you stop answering the same bug fifty times?

Answer it once, on the day you confirm it. Until you do, every report is a new conversation for your staff.

From then on the AI answers the next report from what you taught, in seconds.

Posting is not teaching. The AI reads another channel only when a question points there, and saves nothing it reads, so a post it was never taught does nothing for the next ticket. What the AI can read covers that, and training the AI covers writing a fact it will use.

The last step is the one teams skip. An entry about a bug you fixed last month is now a wrong answer, given with confidence. Teaching the correction is open to staff whose role has Teach the AI. Deleting an entry needs Manage Server.

How do you count the reports of one bug?

With the close reason, because nothing else links two tickets. A ticket bot has no "duplicate of" button. Each report is a separate ticket, and once it closes, the only text your staff can search is the reason it was closed with.

So agree the tag when the bug is confirmed, and put it in every close:

The reason holds up to 255 characters and does three jobs. It reaches the reporter in their closing message, so write it for them. It appears in your log channel with every close, which is free on every plan. And it is what search matches.

Two details bite. Search looks at the last thirty days unless you pick a longer period, and it matches parts of words, so pick a tag that does not sit inside an ordinary word.

For a number rather than a list, export from the dashboard's Tickets page: one row per ticket, up to 1,000, with the category and the close reason in each, ready to count in a spreadsheet. Ticket search and exporting tickets cover both.

Should bug reports be tickets or forum posts?

Both, split by what is in the report. A ticket is private and ends when it closes. A forum post is public and stays.

The rule that matters: anything that could be abused goes in a ticket and nowhere else. A duplication glitch described in a public post is a tutorial. Say so on the panel.

For everything else, let the public post carry the discussion and the ticket carry what is personal: this account, this purchase, this screenshot. In an AI answer channel, a member asking whether a problem is known gets the taught answer in public, without opening a ticket at all.

Should a bug ticket stay open until the fix ships?

No. Close it once you have what you need. Three reasons:

• It holds a slot. A member can have one open ticket per panel on the free plan, and at most three on Premium or five on Pro. A bug ticket left open for a month can block that member's next question.
• It will not sit quietly. On a paid plan with reminders on, a ticket waiting on your staff pings them, twice, and one waiting on the member is closed for silence. Auto-close settings covers both.
• It notifies nobody. Nothing messages a reporter when a fix ships, whether their ticket is open or not, so the announcement has to be public anyway.

So close with the tag and a reason that says where the fix will be announced, then announce it there.

Where a ticket bot stops

The honest list.

Outgoing webhooks, a Premium feature, can tell another system that a ticket opened or closed. They carry the ticket's number and IDs, not the conversation or the close reason, so somebody still copies the report across, or exports the conversations in a batch. Webhooks covers what the message holds.

The list of what is broken and what is fixed lives wherever your developers work.