Discord Ticket Forms: How to Ask the Right Five Questions

What is a ticket form in a Discord ticket bot?

It is the small pop-up that lands on top of Discord when a member clicks a button on your ticket panel. It asks two or three things, the member fills them in, and the ticket opens carrying the answers.

Discord's own name for that pop-up is a modal, which is why nearly every ticket bot labels the feature "modal questions" rather than something a server admin would say out loud. Nothing about it belongs to any one bot. It is a Discord component, every bot that offers forms is drawing the same box, and every one of them inherits the same limits from Discord. That is unusually useful to know, because it means most of what follows is true wherever you end up.

If none of that is set up yet, start with how to set up a Discord ticket bot and come back once you have a panel with at least one category on it. Forms attach to categories, so there is nothing to attach one to until then.

How many questions can a Discord ticket form have?

Five.

That is Discord's cap on the number of fields a single pop-up can hold, so it is not a number to shop around for. A bot advertising ten questions per button is either splitting them across two pop-ups or describing something else.

The part people miss is what the five is counted against. It is per category, not per panel. Every button on your panel carries its own independent set of five. On our Premium plan a panel holds ten categories, so one panel can carry fifty different questions in total while never showing a member more than five at once. Pro raises that to fifteen categories per panel. The free plan allows five categories on its single panel, though it does not include forms at all, which is covered further down.

Two of those numbers are ours rather than Discord's and it is worth being precise about which. Discord would allow a far longer answer field than 1,000 characters. We cap short answers at 100 and long ones at 1,000 deliberately, so that staff can scan a set of answers at a glance and so the context handed to the AI at the start of the ticket stays bounded. A 4,000-character essay pasted into a form field helps nobody: it is a message, and messages belong in the ticket.

What happens when a member opens a ticket with a form?

The order matters more than it looks, so here is the real sequence.

Before the form ever appears, the bot runs its ordinary gate: is this member blacklisted, are they already at their limit of open tickets, does the panel and category still exist, and is the panel inside its working hours. Only then does the form open. If a panel is set to refuse tickets outside its hours, the member is told so and never sees the form at all.

Then the important part. The form opens and the bot stops there. No channel, no ticket number, no staff ping, nothing. All of that happens only after the member presses submit.

Two consequences follow, and both are worth knowing before you write your first question.

An abandoned form costs you nothing. A member who opens the form, reads the questions, and decides to go ask in general chat instead leaves no trace. There is no empty channel for staff to clean up and no ticket counted against anyone. For a big server this is not a small thing, because Discord allows 50 channels in a category and 500 in a server, and channels created by ticket bots are the fastest way to spend that budget. We wrote about that budget in detail in choosing a ticket bot for a large server.

The checks run a second time on submit. The form stays open for about ten minutes and nothing stops a member from opening several of them before filling any in. So when the answers come back, the bot re-runs everything it checked before: still not blacklisted, still under the open-ticket limit, panel and category still there. Without that second pass, five stacked forms would become five tickets from one person. It is also why a member who gets blacklisted while their form is open does not get a ticket out of it.

If spam tickets are the problem you are actually trying to solve, a form helps but it is not the main lever. Stopping spam tickets in Discord covers the settings that do more of the work.

Which five questions are actually worth asking?

Treat it as a budget rather than a form. You have five slots and each one costs the member a few seconds and a small chance they give up. Spend them on what you will otherwise have to ask for.

The single most common way to waste a slot is a field that says "Describe your issue". The ticket already does that. Our welcome message asks the member to describe the problem in as much detail as they can, and if the AI is enabled for that category its first message asks too. A form field that repeats it spends one of five slots on something you were going to get anyway, and it makes the form feel like paperwork before the conversation has even started.

What a member will genuinely not volunteer is the boring identifying detail. Order numbers. In-game names that differ from their Discord name. Which of your three servers they are on. The version they are running. Those are the things that turn into a round trip, and a round trip that happens overnight costs your member a day.

That last one deserves a sentence of its own. A form is a collection point, and everything it collects lands in a channel your staff can read and in a transcript that outlives the ticket. Ask for the minimum that lets you help. If you would not want it sitting in a transcript in six months, do not put a field on it.

Here is the same idea as a starting point per ticket type. Adapt rather than copy: the right questions are the ones your staff currently type by hand every day.

Notice how many of those are one short field. A two-question form gets filled in. A five-question form with three long-answer boxes gets abandoned, and an abandoned form is a member who now has no ticket and a slightly worse opinion of your server.

How do you ask more than five questions?

You do not, on one button. You split the button.

This sounds like a workaround and it is genuinely the better design. A single long form has to serve every case, which means most members read fields that do not apply to them and answer them with a dash or "n/a". Split the same questions across categories and every field a member reads is one that matters to their case.

There is a practical ceiling here too. Categories are buttons on a panel, and a panel with fourteen buttons is its own usability problem. Three to six clear categories is where most servers land, and it is also roughly where the AI stops mis-sorting, since the category decides which questions get asked and which staff role gets pinged.

What do the answers do once the ticket opens?

They arrive in three places at once, and this is the part most guides skip.

In the ticket, as their own embed. The answers are posted alongside the welcome message as a separate block, one field per question, in the order you arranged them. Staff read the context before they read the conversation, which is the whole point.

In the transcript. The answers are written into the transcript as their own entry directly after the header, so an archived ticket keeps the context that opened it. A transcript that says "refund not received" without the order number is an archive of half a conversation. More on what the archive holds in what a ticket transcript actually saves.

In the AI's opening context, if the AI is on for that category. This is the one that changes the shape of the ticket, and it is worth stating exactly what happens.

Without a form, the AI opens with a greeting and waits. It says hello, asks the member to describe the problem, and stops. With a form, it does not greet at all. The answers become the member's opening message as far as the AI is concerned, so the first thing it writes is an attempt at the actual answer.

That first line is the form answers, not something the member typed into the channel. The saving is one full round trip on every ticket in that category, which across a busy server is the difference between a queue and a trickle.

The AI only answers well from a form if it knows your policies in the first place. It is not reading your channels or your rules automatically: it answers from what your staff have taught it. Training an AI ticket bot covers how that gets in.

And if the AI is switched off for that category, which is a sensible setting for appeals and reports, the form is still doing a job. It is just doing it for your staff instead. Gathering is not deciding, and the questions that make a human faster are usually the same ones.

How do you add form questions to a ticket panel?

From the dashboard, or from the panel configuration inside Discord. Both write to the same place, so use whichever you have open.

That last step is not filler. A form reads completely differently from the inside, and the two things you will catch by testing are a label that was truncated at 45 characters and a required field that you did not mean to make required.

On required: make the identifier required and leave the rest optional. A member who genuinely does not have an order number should still be able to open a ticket, and forcing them to type "none" is how you end up with a database of the word "none".

What ticket forms cannot do

This is the section that tends to be missing from vendor pages, so here it is plainly.

No conditional logic. There is no "if they picked refund, show this field". The five fields are flat and everyone in that category sees all of them. Branching is done with categories, as above.

Text only. Short field or long field, and nothing else. No dropdown, no date picker, no checkbox, no file upload. If you need a screenshot, ask for it in the ticket once the channel exists, because that is where the member can actually attach one.

No format checking. You can require an answer. You cannot require that it is a number, a date, or an email. "idk" satisfies a required field perfectly. Design for that: the field exists to prompt the honest answer, not to enforce one.

Not on the free plan here. Forms are part of Premium on our bot, and the free plan opens tickets straight through. Other bots price this differently and a few include it free, so treat it as a line item when comparing rather than assuming. Our free plan article is honest about which side of that line each feature sits on.

Not on tickets another bot opened. If you are running our AI inside a third-party ticket bot's tickets through the connect feature, the other bot owns the whole opening sequence, including its form. We answer inside the ticket once it exists. The full limits of that setup are in adding AI to a ticket bot you already run.

When is a ticket form the wrong choice?

The failure mode worth naming is the form nobody reads. If your staff open a ticket, skip past the answers block, and ask the same question anyway, the form has become a small tax charged to every member for nothing. That is a worse outcome than having no form, because it is invisible: nobody complains about a form, they just fill it in slightly more slowly and slightly more often incorrectly.

The fix is not a better form. It is either deleting it, or working out why staff distrust the answers, which is usually a field that was too vague to be worth reading.

How we checked this

Everything above about the ticket-open sequence, the caps and the ordering was read from the bot's own code rather than from a feature page, which is the only way to be sure about behaviour like whether the channel exists before or after the form.

Roughly half of those tickets closed with no human involved, across more than 3,300 servers, and the first reply lands in seconds. We publish those figures live rather than quoting them here, so you never have to trust a number in an article.