Set up a Discord ticket bot

Before you start

• Use a Build Discord Bots bot that has already been invited to the Discord server you manage and is online. Open the bot detail page before you begin, because server and channel pickers depend on the bot being able to see that guild.
• Prepare a low-risk test rather than using your busiest channel. Confirm the bot’s Discord permissions before changing Tickets; dashboard settings store intent, but Discord still decides whether the bot can see, send, connect, manage, or moderate.

1. Open the correct module and server

   Open the bot detail page, select Modules, and enable Tickets before editing its card. Choose the target guild in Module Settings, then use Ticket System, Panel, and Ticket Categories as separate areas: a panel is the public place a member starts, while a parent category and staff role govern the private channel created afterward. The bot must be online to populate guild choices. Before you publish anything, use /ticket ticketcheck to inspect its channel, role, message, and history requirements. Its role must be above any role it will manage; a panel that looks correct cannot override Discord’s hierarchy.

2. Set the destination and core controls

   In Ticket System, choose the Ticket Parent Category, Ticket Panel Channel, and Support Staff Role before publishing anything. Enable Tickets Module, then use Panel Title, Panel Description, and Ticket Welcome Message to explain what support members will receive. Ticket Log Channel is for staff records, not the member-facing panel. Keep Max Tickets Per User low for the first test and use a distinct Ticket Channel Prefix, so the test ticket is easy to identify and close without confusing it with a real request.

   Set the Ticket Parent Category only if you want ticket channels grouped there; None means the module does not have a parent category to use. Choose a Ticket Panel Channel for the public entry point, then add a Support Staff Role that should access all ticket channels. The panel’s title, description, prefix, and welcome message are separate fields, so write the panel as an instruction and the welcome message as the first private reply. Run /ticket ticketpanel to use the saved panel channel; test /ticket ticketcheck before publishing if Discord has recently changed the bot role or permissions.

3. Save and confirm the dashboard state

   After choosing the parent category, panel channel, support role, and maximum open tickets, click Save Settings and look for Saved ✓. That saves defaults; it does not post or refresh a panel by itself. Run /ticket ticketpanel in the selected panel channel only when the wording and staff role are ready, then use /ticket ticketcheck if a recent role or channel change is involved. If the dashboard reports a sync issue, restart the bot from its detail page after recording the settings you expect to see. Reopen the Tickets card and verify each saved field rather than recreating several panels, because duplicate public panels confuse members and are not evidence that access overwrites work.

   Leave Close inactive tickets off unless the server wants this policy. When enabled, choose the number of quiet hours before a visible warning and the additional quiet hours before closing. A human reply resets the clock; bot and system messages do not. The bot never closes a ticket without first posting the warning. Managers can use /ticket ticketinactivity action:exempt inside a ticket to exclude it, and /ticket ticketinactivity action:include to put it back into the policy.

4. Run the module’s real test

   Run one controlled ticket-panel click. For this module, use /ticket ticketpanel and /ticket ticketcheck where a command is appropriate, or click the posted panel from a human account. A member should be able to use the posted panel to create a private ticket channel with the configured support access. Check both the public destination and any staff-only log channel you selected. Use a fresh event or command after every correction: a module normally reacts at the moment Discord emits the event, not when a setting is later changed. Do not use a bot account as the test member unless the module expressly supports bot-authored activity; many safety-oriented handlers ignore it.

5. Diagnose the common failure path

   If a panel click creates no ticket, check the selected server, enabled Tickets module, panel channel, category, and support role. A visible panel alone is insufficient: /ticket ticketcheck reports the needed channel, role, message, and history permissions, and the bot role must sit above roles it manages. Do not use a broad Administrator grant as a shortcut. Fix the reported permission or hierarchy issue, click the panel again from a human account, and confirm that the new private channel contains the configured support access and welcome message.

   Choose ticket categories by the kind of request members can understand, not by every internal department name. The settings UI lets you create a panel that is readable before someone opens a channel, while the module applies the configured support role to the private space. Use a test member who does not have the support role, open one ticket, and confirm that staff can see it but the test member cannot open more than the allowed amount. Then close or clean up the test channel. This confirms both the user-facing panel and the permission overwrites rather than merely proving that the dashboard saved text.

6. Review tiers and keep the setup maintainable

   When tier caps are enforced, Free includes one ticket type and one open ticket per user; manually requested transcripts and priority are Pro. An automatic inactivity close can archive its transcript in the configured Ticket Log Channel. Pro removes those ticket-type and open-ticket limits. The right way to validate a configuration is to test the actual control and result rather than assume it will remain available on Free. Keep a short moderator note describing the server, destination, and test command or event. Revisit Ticket System, Panel, and Ticket Categories after major role, channel, or permission changes. A configuration that was correct when the bot was invited can cease to work after a role is moved, a channel is archived, or the bot loses access.