Modmail

How modmail works

Modmail puts the bot between members and staff. A member clicks Contact staff, describes their issue in a modal, and gets a DM confirmation — from then on, everything they send the bot is relayed to staff, and every staff reply is relayed back. Two messages live in your server: the public contact embed members click, and the staff admin panel that lists open tickets and hands them out.

Setting it up

Configure modmail on the dashboard's Modmail page, in this order:

• 1. Enable modmail — the master switch. While disabled, the contact button politely refuses.
• 2. Pick staff roles — members holding any of these roles can claim, answer, transfer, and close tickets, and can see ticket channels.
• 3. Pick the admin channel — a staff-only channel where the panel and new-ticket pings live.
• 4. Post the admin panel — one persistent embed showing open / claimed / closed counts and the oldest open tickets, with Claim next and Refresh buttons. It is posted once and edited forever — never reposted, never spammy.
• 5. Send the contact embed — the public message with the Contact staff button. The embeds, button label and style, and the modal's title and prompt are all editable, using the same embed editor as registration.

A few optional settings tune the rest of the flow:

• Log channel — a channel that collects ticket lifecycle events (opened, claimed, transferred, and closed, with the transcript link), keeping a durable record separate from the live admin panel.
• Ping staff on new tickets — when on, the staff roles are pinged in the admin channel the instant a ticket opens, and the ping is deleted right away. Turn it off if the admin panel is notification enough.
• Let members close their ticket — adds a Close ticket button to the member's DM so they can wrap up once their question is answered.

The ticket flow

From the member's side:

• They click the button and describe their question in a modal.
• The bot DMs them a confirmation with their ticket number and their message. If their DMs are closed, the ticket is not created — they are asked to enable DMs and try again, so no ticket can ever exist that staff cannot answer.
• From then on, anything they send the bot in DM is added to the ticket and relayed to staff.
• If Let members close their ticket is enabled, their DM also carries a Close ticket button, so they can close it themselves once they're done.

From the staff side:

• With Ping staff on new tickets on, a staff-role ping is posted in the admin channel and deleted instantly — the roles light up as a notification without leaving clutter behind.
• The admin panel updates its counts and ticket list: 🟢 open, 🟡 claimed, ⚪ closed.
• Closing a ticket DMs the member a closed notice (with the optional close reason and your configured closing text). In channel mode the ticket channel is deleted a minute later.

Claiming & transfer

Staff never pick tickets — Claim next assigns a random open ticket to the clicker. Random assignment spreads load evenly and prevents cherry-picking easy tickets. The member is told their ticket is being handled; the claimer gets the ticket's opener and recent history.

In channel mode, claiming makes the ticket private: the channel is locked to the claiming staff member and other staff lose access — one owner per ticket, no crossed wires. The member never notices; they keep talking to the bot in their DMs.

A claimed ticket can be transferred to another staff member — the Transfer dropdown lists only staff (members with a staff role or the Manage Server permission), never the whole server. Both staff members and (in named mode) the member are notified. If the assigned staff member becomes unreachable, the ticket automatically reopens and staff are pinged again.

Channel vs DM relay

Where staff answer from is a per-server choice:

Anonymous vs named staff

With anonymous staff (the default), members see replies from "the staff team" — no individual names, no targets for arguments or harassment. Switch to named mode and replies show the staff member's name and avatar, including on claim and transfer notices.

Private notes

Start any staff message with // and it becomes a private note: saved on the ticket and visible to staff, never relayed to the member. Use it for context, hand-over notes, or coordinating before answering.

Transcripts & logging

When a ticket closes, the bot generates an HTML transcript of the whole conversation. The link is DM'd to the member with their closed notice and posted to the log channel, so both sides keep a copy. Transcripts are hosted at https://modmail.zyron.pro/transcript/<id>.html and are deleted automatically after 14 days.

Internal // notes are never written to the transcript — it holds only what the member and staff actually exchanged.

The log channel collects the full ticket lifecycle — opened, claimed, transferred, and closed with its transcript link — as a durable record alongside the live admin panel.

Open-ticket limit

Each member can have a limited number of tickets open at once — 1 by default, configurable up to 5. A member at their limit is pointed back to their existing DM conversation instead of opening a duplicate. Members on your blocklist cannot open tickets at all; they get the same generic "not available" response as when modmail is disabled, so the blocklist is never disclosed.

Next steps

Ticket activity is observable from the outside too: modmail.ticket.created, modmail.ticket.claimed and modmail.ticket.closed events are delivered to your webhooks, and every action lands in the logbook.