How to Add Someone to a Discord Ticket, and What They Can Read

Halfway through a ticket you hit the thing you cannot answer. The developer who knows why the build crashes, the moderator who was there when the ban happened, the one person who understands your payment provider. None of them are on the ticket, and screenshotting half a conversation into another channel is worse than it sounds.

There is a command for this and it takes four seconds. What deserves reading is what it does to the ticket, because it is less reversible than it looks.

How do you add someone to a Discord ticket?

Run /ticket add in the ticket and pick the person. There is nothing to set up first and no plan gate on it.

Both need Manage Server, or a staff role holding the claim or close permission. It is the same group that can end a ticket, on the reasoning that anybody trusted to close a conversation can be trusted to widen it, so there is no separate permission to hand out. Discord ticket bot permissions covers how those roles fit together. Members cannot run it, so nobody can pull a friend into their own ticket.

Three things then happen at once, and none of them is quiet.

The notice carries a real mention, so the person you added gets a notification rather than a channel they never look at. They also get a direct message naming the ticket, the server and who added them, with a button that jumps straight in. And the notice becomes part of the ticket's record, so the transcript written at the end shows who was brought in and when.

The command allows five uses a minute per person: plenty for a real case, not enough to add a whole role one name at a time.

What the person you add can suddenly read

This is the part worth stopping on. Discord has no way to say "from here on": access to a channel is access to its history, and the bot grants exactly that, so the moment somebody is added they can scroll to the first message and read all of it.

In practice that is the answers the member typed into your panel form, whatever they pasted while they were frustrated, the order number, the screenshot with their real name in the corner, and anything your team said in the channel while assuming three people were in the room.

So the question is not who could help with this ticket. It is who should be able to read it, which is a different question and the only one of the two you cannot answer after the fact.

Two habits make it a smaller decision every time. Keep the internal half of a conversation out of the ticket channel, because a ticket is a room the member is standing in and you may widen it later. And when you need one fact rather than a colleague, ask in a staff channel and paste the answer back yourself. Nobody needs to read a stranger's billing history to tell you whether refunds are open this month.

What removing them does, and what it cannot undo

/ticket remove is the mirror image and it takes effect immediately. In a channel ticket their access is dropped and it disappears from their sidebar; in a thread ticket they are taken out of the thread. Either way they get a direct message telling them, with no jump button on it, because there is nothing left to jump to.

What it does not do is unhappen. They read what they read, it sits in their client until Discord forgets it, and nothing is redacted afterwards. Removing somebody is tidying up, not an undo.

It does leave a trail, on purpose. Both halves are written into your audit log with who ran the command and who it was run on, and both notices stay in the transcript the member is sent at the end. If somebody ends up in a ticket they had no business reading, how they got there outlives the ticket.

One gap worth knowing before you lean on the tidy-up: nobody you added is told when the ticket closes. The closing message, the transcript and the rating button all go to the member who opened it. Anybody else finds the channel gone one day.

To the bot, anybody who is not the opener is staff

There is one test underneath all of this: is the person writing the one who opened the ticket? Everybody else is treated as staff, including somebody you added five minutes ago because they were part of the story.

The first line catches people out. Most servers run with the AI standing down as soon as a human joins in, which is the right default when the person you added is taking the ticket over. It is not what you want when you added the member's friend to confirm one detail, because their single message ends the AI's part in a ticket it was handling. /ticket ai enable turns it back on for that ticket.

The last line matters if you borrow the same person often. When a ticket closes the bot records who did the work, and anybody who is not the opener is eligible, including a guest there for one ticket. It is not a raw message count: the cut-off is three quarters of whatever the busiest contributor sent, so a line dropped into a long ticket earns nothing while somebody who ended up handling it is credited properly. Anonymous staff replies covers the same snapshot from the other end.

Roughly half of all tickets across every server running this bot close with no human replying at all. Adding a person is one of the ways a ticket leaves that half permanently, which is a reason to do it deliberately rather than by reflex. Current figures are at /api/stats/global if you would rather check than take our word for it.

Why the person you added still cannot see it

Two shapes of ticket, two ways this fails, and the second one is silent.

Ticket channels. Changing who can see a channel needs Manage Roles on the bot's own role, not Manage Channels, which is the one people get wrong. Without it the command refuses and names the permission it wants. Any server where tickets open at all already has it.

Ticket threads. Tickets that open as private threads behave differently. The bot adds the person to the thread, which is usually the whole story, except that Discord has a rule underneath: to see any thread in a channel you have to be able to see the channel it lives in, and being added does not override that. So when your ticket threads sit under a staff-only channel and you add somebody who is not staff, the command succeeds, the direct message arrives, they press the button and land on nothing.

A third case looks like a fault and is not: a thread left quiet long enough for Discord to archive it refuses to be edited at all, so the bot wakes it first. That is why the command takes a beat longer in an old ticket.

Add a person, or move the ticket?

Moving is the better instinct when the ticket itself belongs to another team, because ticket categories carry their own responsible role and their own routing. Read what a transfer does not do first, though: it does not rewrite the channel's permissions either, which is why /ticket add is often what gets one specific person into one specific ticket.

Adding is better when the ticket is yours and a single piece of it is not. How a support team is structured makes the staffing case: borrowing somebody for one ticket is how a role list stops growing.

Where this is the wrong choice

Two more limits before you build a habit on it. Nobody can be added or removed from the web dashboard: staff do this inside the ticket, and the dashboard is the admin's surface rather than the shift's. And you cannot target the person who opened the ticket, or the bot, which sounds obvious until you try it on a ticket somebody opened on a member's behalf.

Used carefully this is a small feature that saves a lot of copying and pasting, here and on most other Discord ticket bots. Used carelessly it is how a conversation somebody had in confidence gets read by six people who were never part of it.