UNITEDBuild a Support Ticket Workflow with United
A good ticket system sends the right request to the right staff, collects enough information to begin, and preserves the conversation before access is removed.
Start with the work, not the panel
List the reasons members contact staff. Most servers need only a few clear types: General Support, Staff Report, Purchase Help, Partnership, or Appeal Information. Too many choices slow members down and create categories nobody maintains. Each United ticket type stores a public label, an optional emoji, a destination category, selected staff roles, and optional questions.
Choose access independently for every type
Role access is attached to the ticket type. If Staff Reports should be visible only to Server Lead and Administrator, select only those roles. Support and trial staff should not receive a ping or channel overwrite merely because they can work General Support. Discord administrators can still access channels through their administrator permission.
Category overwrites also matter. A category-level View Channel allow can expose every child ticket to a role before the ticket-specific overwrites are considered. When an unselected role can see a ticket, inspect the category in Discord before changing United's saved roles.
Ask only questions staff will use
United supports up to five questions per ticket type. Ask for information that changes the first staff response: an order number, the person being reported, the rule involved, the expected outcome, or what troubleshooting has already been tried. Avoid requests for passwords, authentication codes, payment card numbers, government identification, or other secrets.
Use the dashboard question editor or ,ticketquestions. The member completes the form before the channel is created, so question wording should be understandable without staff present.
Publish one panel in an existing channel
After types, categories, roles, and questions are ready, edit the panel title and description and select the existing channel where it belongs. Publishing should reuse the saved panel. Use Refresh Panel when the text or options change. Repair is for a missing saved panel, not ordinary edits.
Use a predictable ticket lifecycle
| Stage | Expected action | Record kept |
|---|---|---|
| Open | Member submits form; United creates the channel and applies type access | Creator, type, reason, answers, created time |
| Claimed | One staff member takes ownership while others can still assist | Claimer and claim time |
| Waiting | Staff marks that the next response is expected from the member | Desk status and latest activity |
| Closed | United saves a transcript and removes normal member sending access | Transcript, closer, reason, close time |
| Reopened | Authorized staff restores the ticket workflow | Reopen actor and reason |
| Deleted | United verifies transcript delivery before deleting the channel | Final transcript and delete action log |
Separate inactivity from member discipline
,tickettimeout 24h sets the inactive auto-close window for tickets. ,tickettimeout @member 10m stops that member from sending in the current ticket for ten minutes. ,tblock @member 1h prevents new ticket creation for one hour without closing their current ticket or applying a server-wide Discord timeout.
Place transcripts intentionally
Ticket actions use Bot Logs by default. Set a dedicated transcript channel with ,ticketlogs #ticket-transcripts when staff needs a searchable archive separate from daily events. United records the original ticket name before deletion so a transcript should not be labeled unknown merely because the source channel no longer exists.
Design for restarts and mistakes
Open ticket records, controls, creation blocks, and member-specific ticket timeouts are stored persistently. After a restart, United restores controls only in known open-ticket channels. Database uniqueness checks should prevent two active records for the same ticket, while panel discovery prevents repair from creating a second public setup around a working panel.