Set support up once, properly.

Last updated: August 2026

The model, in four words

Almost everything in Zextra follows one chain, and knowing it makes the rest of the dashboard obvious:

Panel → ticket type → form → ticket.

• A panel is a message in one of your channels. It has a heading, a line of context, and buttons.
• A ticket type is one of those buttons, one kind of request, like Billing or Appeals. A panel can offer up to 25.
• A form is the questions a ticket type asks before anything opens. Optional, and reusable across types.
• A ticket is the record: who asked, what they answered, who owns it, what state it is in, and how long it took.

The conversation itself is a Discord thread. Zextra never stores message content, it stores everything around it.

What is live today

Zextra is in early access, and the split is worth knowing before you spend an evening on setup. The dashboard is finished: everything below can be built, saved, edited and reasoned about right now.

The support runtime: posting your panel, opening a private thread when a member presses a button, showing your form and storing the answers, running your open-a-ticket rules, and letting staff change a case from inside the thread with /claim, /resolve and the rest, runs on the same service that serves this dashboard. Whether it is switched on for your server is shown on every screen it affects.

Two things are still genuinely missing, and the dashboard says so rather than letting you assume otherwise. Both need Zextra to watch your server rather than answer it, which is a different kind of connection:

• Response times. Recording the first staff reply means noticing a message nobody asked us about. Until that exists, first-response figures read as no data rather than as zero.
• Rules that wait or watch. “When a ticket goes quiet” needs a timer; “when a message matches a keyword” needs to see the messages. Both save, and both are marked as not firing yet.

Nothing you configure is throwaway. It is stored against your server and starts working when the piece it needs lands.

1. Connect a server

Sign in with Discord and choose a server. Zextra shows every server where you have Manage Server, whether or not it has been added yet, so the one you want is one click away rather than hidden behind an install.

Adding Zextra to a server asks for a short, specific permission set, and the security page lists each one with what breaks without it. It never asks for Administrator.

2. Build a panel

Go to Panels and create one. Give it a name and a description, both are what members read, and choose the channel it belongs in. If Zextra can see your server it offers a real channel list; if not, it takes a channel ID.

Every new panel starts with one ticket type. Open it, rename it to something a member would recognise, and add more for each distinct kind of request. Each type can have:

• a button label and an optional emoji
• a line of description under the button
• a form to ask first, or none
• a channel to open its threads in, if it should not be the panel’s own

The preview beside the editor is the message as members will see it, and the list under it spells out what each button does when pressed.

3. Ask for what you always end up asking for

A form turns “hello?” into a ticket someone can act on. Build one under Forms, then attach it to a ticket type.

• Question types are short answer, paragraph and dropdown.
• Helper text under a question is where you say what a good answer looks like.
• Each question has an answer key: a short stable name like order_number. Answers are filed under it, so rewording the question later does not orphan the answers already collected.
• Five questions, maximum. Discord shows a form as a pop-up, and a pop-up holds five inputs. Ask for the five things you always end up asking for; the thread is what the rest of the conversation is for.
• A dropdown is a short answer with its options listed as a hint, because a Discord pop-up has no dropdown. What the member types is checked against your options before the ticket opens.

Answers appear on the ticket under Request, and are posted into the thread as the first message, so whoever picks it up has the context without opening a browser.

4. Work the queue

Tickets is one list of everything, filtered and counted in the database, so a status count describes your whole server, not the page you are looking at. Filter by status, ticket type or assignee, or search subjects and IDs.

Claim a ticket to take ownership of it. This is the mechanism that answers “who is dealing with this”, and the overview shows unclaimed open tickets as its own number because that is the thing worth fixing today.

You can do the same things from inside the thread, and it is the same change, same record, same history, same rules about what a case may become:

• /claim and /release: take a case on, or put it back.
• /assign and /transfer: hand it to somebody. Assign is for a case nobody holds; transfer takes one off whoever does.
• /waiting, /resolve, /archive, /reopen: move it through the lifecycle below.

Who may use them is your staff roles setting, not a Zextra account. Somebody who answers tickets in Discord needs no dashboard access at all.

5. The lifecycle

Four states, and each one says who is being waited on:

• Open: waiting on your team.
• Waiting on member: you have replied and cannot go further.
• Resolved: answered, not filed away yet.
• Archived: filed. Reopening puts it back in Open.

An archived ticket can only be reopened, not moved sideways into another state, otherwise a filed ticket could claim it was waiting on a question nobody asked. Deleting a ticket removes it and its answers permanently; who deleted it stays in Activity.

6. Automate the repetitive part

Rules read as a sentence: when something happens to a ticket, do something. The vocabulary is deliberately small, because a rule engine nobody can predict is worse than none.

• Triggers: a ticket opens, a ticket goes quiet for N minutes, a ticket closes, a message matches a keyword.
• Actions: post a message in the thread, notify a role, change the status, close the ticket.

New rules start switched off, so nobody discovers what their rule does by watching it fire. Running rules against live tickets is part of the Discord runtime.

7. Who can do what

There are two separate ideas here, and conflating them is the usual mistake.

• Staff roles (under Settings) are Discord roles allowed to work tickets in your server.
• Dashboard access (under Access) comes from having Manage Server in Discord, narrowed by a Zextra role: Staff work tickets and read analytics; Admins also configure; only Owners change other people’s access.

Changing one does not change the other today. Every configuration change is recorded under Activity with who made it and what moved, kept even after an account is removed.

Something unclear, or missing? Ask in the community Discord →