Tickets

The job these bots do

A ticket bot turns a support request into a private channel of its own. Someone who needs help presses a button; the bot creates a channel that only they and the responsible team can read. When it is done, the channel closes and a transcript remains.

The gain is less about technology than about order. Without a ticket system, questions land in general chat, sink, get asked three times, and nobody knows whether anyone is dealing with them. With one, every request has a place, a state and an owner.

Features that actually matter

Several topics, several paths. An application, a complaint and a technical question go to different people. A usable ticket bot offers multiple categories, each with its own responsible role and its own opening message. A bot with a single button forces your whole team to read everything.

A form before the channel. The better implementations ask two or three things before opening: what is this about, which version, which server. That saves the first follow-up question, which is the expensive one, because hours often pass between it and the answer.

Transcripts worth having. Check the format. A text file beats nothing; an HTML file with timestamps and attachments is considerably better. Check where it lives, too: on somebody else's server, or in a channel you control. Where personal information is involved, that is not a matter of taste.

Limits against abuse. Without them, one bored member opens fifty tickets. A per-person limit, a cooldown between tickets and automatic closure after days of silence are requirements, not decoration.

Permissions worth checking

Ticket bots need Manage Channels to create and delete channels, Send Messages and Read Message History for transcripts, and usually Manage Roles when responsibilities are modelled as roles.

Manage Channels is broader than it sounds: anyone who can create channels can also delete them, all of them, not only their own. Put ticket channels in a dedicated category and, where the bot allows it, scope its permissions to that category.

A ticket system does not need Administrator. When one asks, it is almost always because it also ships moderation features you never wanted.

Where server owners go wrong

The first mistake is a ticket system with nobody behind it. A button nobody answers is worse than no button: it promises help and delivers none. Set the system up once you know who is on duty.

The second is transcripts on somebody else's infrastructure. Support conversations routinely contain personal information. A transcript stored with a service you know nothing about is a disclosure to a third party, with everything that legally entails.

The third is over-asking up front. A form with eight required fields means nobody asks anything. Three fields is roughly where people start abandoning.