Discord Ticket Bot for Multiple Servers: What Carries Over

The second server always starts the same way. The bot is added, /setup runs, a panel appears, and then somebody asks where the staff roles went, why the AI has never heard of the refund policy, and why the member who was blocked last week just opened a ticket here.

None of that is a fault. A Discord server is a closed room: its channels, roles and members exist nowhere else, and a Discord ticket bot that respects that treats every server as its own install. This guide is for anyone running more than one, whether a game network, a studio with a Discord per title, regional communities or a main server with a staff server: what stays behind, what comes with you, and how to set up the next one quickly.

Can one ticket bot run in several Discord servers?

Yes. You add the same bot to each server and it serves all of them at once, with nothing extra to host. What it does not do is treat them as one system. The bot checks the boundary on every save: point a panel, a log channel or the public AI channel at a channel in another server, and the save is refused.

That refusal is a safety rule before it is a limitation. A setting that could name any channel the bot can reach would let one server's setup post into another community, so the line sits at the server edge, and everything below follows from it.

Some rows work in a network's favour. The language setting is per server, so regional servers can each run the bot's buttons and messages in their own language, and on a paid plan whitelabel gives each community its own bot name and avatar.

Only two rows are shared, and both are about a person rather than a server. Your dashboard sign-in lists every server you own or manage, with the ones missing the bot marked, but each server's pages are about that server alone and there is no combined ticket list. And a member who runs /mytickets in a direct message with the bot sees every server they have opened a ticket in, so a player can find tickets from three of your servers in one place even though your staff cannot. Ticket history covers what that list shows.

Setting up the second server without starting over

Most of the work in the first server was deciding things: which categories, who handles what, what the AI should know. None of that has to be decided again. It has to be repeated.

The presets keep staff permissions consistent. There are fourteen separate permissions, and a role rebuilt by hand in a fourth server is where drift starts. The staff role editor, in Discord and in the dashboard, offers four starting sets (Support agent, Support lead, Moderator and AI trainer), so "the same role as in the main server" is one press.

The panel editor has templates, but a template is a starting layout, not a copy of your first panel. There is no export and import between servers, so keep your panel wording in a shared document and paste it in.

Saved replies are the place to be selective. Each server has its own library with its own plan limit, so copy the replies your staff reach for daily, not the forty written for one event.

Giving every server's AI the same answers

What you teach one server's AI is never visible to another. That is a privacy rule, and per-server memory explains it. For a network the consequence is practical: shared knowledge has to be taught to every server that needs it, and the way to keep that manageable is to give it one home.

/ai train accepts a link and reads that page plus related pages on the same site, up to ten per job, and it takes files: text, Markdown, CSV, JSON, PDF and Word. So one rules page or one PDF can be taught to every server with the same command. Each job is paid from that server's own AI allowance, so three servers cost three jobs.

What this does not do is keep them in sync. Nothing re-reads the page on a schedule, so when it changes, train again in each server that needs the update.

The separation has an upside. A server with a different refund window or different staff hours can be taught its own version, and the others never repeat it by mistake. Training an AI ticket bot covers what to teach first.

One staff team across several servers

Discord decides most of this. A staff member only sees ticket channels in servers they belong to, and a staff role is a role in one server. So a team covering four servers means four memberships and four role assignments per person, and the dashboard needs Manage Server in each server separately.

What you can centralise is the alert, not the work. Log channels, the free way to post ticket activity into Discord, must sit in the same server as their panel, so they cannot feed a separate staff server. Outgoing webhooks can. On Premium and above, each panel can send its opens, claims, closes and transfers to one address, and when that address is a Discord webhook, the bot posts one line into that channel, such as "Ticket #42 opened".

That line carries no link and no names, which is the trade-off: it tells the staff server that something happened and where, and someone still opens the ticket in its own server. For a feed inside one server, log channels are free and post a proper summary with a jump button. The webhooks guide covers the rest.

Blocking someone across your servers

This is the gap networks feel first. A block applies only to the server it was added in, so a member blocked in your main server can still open tickets in every other server you run, and nothing warns anyone.

There is no network-wide blocklist you can manage. The fix is a habit: when a reason applies everywhere, such as a scam attempt or harassing staff, block them in each server the same day. The dashboard and the /blacklist command both take a member or a whole role, and staff given the blacklist permission can use the command without Manage Server.

Blocks placed by the AI stay local too. When it blocks someone for spam in one server, that decision and its audit record live in that server, and a person has to carry it across. Stopping spam tickets covers what a block does and does not stop.

Paying for several servers

Free, Premium and Pro are per server. A plan applies to the one server it was bought for, so a second server runs on Free until it gets its own, and each server can sit on a different plan: Pro on the busy main server, Free on a small one. The 14-day Premium trial works the same way: a server on Free gets one, once, when it publishes its first panel, with no card.

Enterprise is the exception, and since September 2026 it is built for this case. One Enterprise contract covers several Discord servers on a single price, with the same limits and features across all of them and one renewal date. Servers can be added or removed while it runs, and a server added mid-contract starts straight away and renews with the rest. It is agreed with us rather than bought with a button, so it suits a network where one bill matters more than per-server flexibility.

When one server is the better answer

The bottom half is what this bot does not do across servers, stated plainly: no combined queue, no shared blocklist, no automatic sync of what the AI knows, and no log channel that reaches into another server. If those matter more than the separation, the answer is usually one server with more ticket categories, each wired to its own staff role. A Minecraft network with several game servers behind one Discord is the common case, and our Minecraft guide argues for a category per game server.

If the separation is the point, and for most networks it is, the work is front-loaded: decide once, repeat it in each server, and keep the shared knowledge in one place.