Onboarding Discord Moderators: The First Week, In Order

Nearly every Discord server onboards support staff the same way. Somebody gets the role, gets told to ask if they are unsure, and learns the server by getting things wrong in front of members. It works eventually, at the cost of the first thirty tickets and, often, the person.

The fix is not a handbook nobody reads. It is putting three things in the right order, and knowing which of them your ticket bot already holds.

How do you onboard a new Discord moderator?

Short answer: give them reading before you give them replies, then let them reply narrowly before you let them reply freely. Three phases, and the first one involves no members at all.

Staging it matters because support answers are server-specific. A new moderator is not learning how to be helpful, they are learning what your server says about refunds, about appeals, about the thing that broke last month. None of that is in a general moderation guide. All of it is in your ticket history.

That last row is the one people rush. Teaching the AI is not a reward for good behaviour, it is a permission that rewrites what every future ticket gets told.

What should a new moderator read first?

Short answer: your own closed tickets, filtered down to the ones a human had to finish.

There is a problem specific to ticket bots here. On a normal Discord server a new moderator learns by lurking, scrolling a support channel and watching how things get handled. A ticket bot removes that. When a channel-mode ticket closes the channel is deleted, and thread-mode tickets are archived and locked with the participants taken out, so neither leaves a back catalogue. There is nothing to scroll.

What replaces it is better, as long as somebody points at it. Every closed ticket leaves a transcript, and the staff search command narrows that archive into a genuine reading list.

Each result opens into a detail card with a button straight to the transcript, and any staff role holder is authorised to open it. Ten of those beats any document you could write.

The first filter is the one that matters, and it is worth saying why. Across the bot's lifetime, roughly half of all tickets have been resolved by the AI with no human involved at any point, out of more than 180,000. Those are the ones with a single right answer. Your new moderator will never see them, so a random sample of your history teaches them the easy half of a job they will not be doing.

That split is checkable rather than something you take from us: /api/stats/global is a public endpoint with no authentication, and it is the same source our homepage counters read.

What should a new moderator be allowed to do on day one?

Short answer: claim, close, and use the answers somebody has already written. That is what a staff role gives you by default, and it is the right starting set.

A staff role in AI Ticket Bot carries five switches, covered in full in Discord support team structure. Four are on when you add a role. The fifth, train AI, is off, and that default is the whole onboarding policy.

Saved replies are the underrated half of this. Writing them is admin work: adding, editing and deleting a quick response need Manage Server, while using one only needs a staff role that can claim, close or transfer. That split is what you want during onboarding, because somebody senior writes the wording once and the new person picks from a list instead of inventing policy at 2am. The free plan holds 5, Premium 50 and Pro 200.

What happens the moment they reply in a ticket?

Short answer: on most servers, the AI stops. That setting ships on, and it is the single most useful thing to tell somebody on day one.

That is a feature rather than a trap: two voices answering one member is worse than either alone. It only becomes a problem when nobody has told the new person, which is why it belongs on the list before their first shift.

The companion habit is anonymity. Both the reply command and the saved response command can post under a generic Staff label, so the member sees an answer from the team rather than a name they can follow into DMs. New helpers are the ones who end up DMed personally for months, and a week of replying as Staff prevents most of it. The record underneath still stores the real author, so activity credit and your dashboard staff view are unaffected.

How does a new moderator get help without leaving the ticket?

Short answer: by pulling somebody in, or by asking the bot first.

The add command grants one named person access to one ticket, and remove takes it back. Any staff member who can claim or close may use it, on every plan including free. During onboarding it works as a mentor button: the new person keeps the ticket, the experienced one is present for the awkward part, and neither needs a permission change.

Asking the AI is the quieter option, and it has no permission gate at all. Anybody can ask the server's own AI a question in a channel and get the answer it would give a member. A new moderator unsure what your refund window is can ask, then say it in their own words, which is faster than waiting for a human and more accurate than guessing.

When the answer is genuinely above them, that is a handoff rather than a question, and Discord support escalation covers which role gets pinged.

What a ticket bot will not do for onboarding

This is the thinnest part of ticket tooling generally, ours included, and it is worth knowing before you build a process on top of it.

Retention is the other limit. Transcripts are kept 90 days on free and 730 on paid, so on free your reading list reaches back three months. Usually plenty, unless your hardest tickets are seasonal.

Measurement is thin too. Ranking a new person by tickets closed teaches them to race for the Close button, which Discord support analytics covers in detail. The honest early signal is the star rating members leave on a closed ticket, described in how to close a Discord ticket, and even that needs a few weeks before it means anything.

A first week, in order

None of this needs a document. It needs somebody to decide the order once, and the order is what servers get wrong: the role first, the reading never, and the AI training switch handed over on day three because that was easier than explaining it.