Discord bots as a product surface
A Discord bot should live where the community already talks. Design a few commands, help text, and a real way to reach a person.
Use a discord bot for community as a small interface in a room that already exists. It should do a few known jobs, reply with what just happened, and offer a person when the command is the wrong tool.
Members will use a bot that behaves like a clear screen. They will mute one that behaves like a mascot. Design the commands first. The personality, if you add one at all, comes last.
Put the bot in the room people already use
A community has a home before you add software. For a lot of early products that home is a Discord server: an announcements channel, a support corner, and the thread where people answer each other. A bot belongs there when the job is something that room already does, often enough that a person is tired of repeating it.
Useful jobs stay short:
- A status check a member could otherwise only get by asking in public.
- An intake with the three fields you actually need, such as a name, a plan, and what they are trying to do.
- An alert the team has already agreed to send, posted in the channel they already watch.
- A pointer to the one doc that answers a question you heard twice this week.
The product can stay on the web. The bot should not pretend to be a second app with menus, settings, and a learning curve. If people have not asked to live inside chat, a command that tries to replace the product will feel like a side door with no map.
Hanabi designs and builds Discord bots as one of the smaller offers beside a site or a product interface. The studio standard still applies: clarity over complexity. One command that does one thing is easier to trust than a command that tries to run the company.
Design each command like a screen
A command is a control. It needs a name a member can remember, a result they can check, and a failure that says what to do next. Five commands a person can recall will beat twenty they have to look up every time.
Name them as verbs the community already uses. /status, /apply, and /ask are easier than internal ticket codes. If the team says "access" and the command says "provision," you have invented a dialect. Use the room's words.
Each successful reply should answer three questions:
- What did I just do?
- What happens next, and roughly when?
- What do I do if this is wrong?
Permissions are part of the design. A command that posts to the whole server is a different product from a command only moderators can run. Say who can use it in the help line. A member who tries a moderator command should get a plain refusal, not an error that looks like a crash.
Write the empty case too. If someone runs /status before they have an account, the reply should say that, and say how to get one. A blank embed is the same as a blank screen in a product: the person assumes the thing is broken.
Write help a member will actually read
Help text is the interface, not an appendix. Nielsen Norman Group's 2011 article on how long people stay on web pages is a useful constraint even in chat. Users often leave a page in 10–20 seconds, and they have time to read only about a quarter of the text on the pages they do visit. A help reply written like a manual will be skipped.
Put the command names and one-line outcomes in the first message. Put edge cases behind a narrower command, such as /help apply, rather than in the opening wall of text. The first reply is doing the job of a homepage: what is this, and what can I do.
Test the help by pasting it into the server and reading only the first four lines, the way a hurried member will. If those lines do not name the commands, the help has failed, however complete the rest of it is.
Keep examples in the help concrete. "Try /apply with your work email" is a lesson. "Use the apply command to initiate the onboarding workflow" is a brochure. The bot can be calm and still be specific.
Leave a door to a person
Some questions are not commands. A billing dispute, a ban appeal, or a "this looks wrong" needs a human. The bot should say so in the same voice as the rest of the server, and it should do something concrete: open a private thread, mention the role that is actually on duty, or hand over a short form a person will see.
The handoff has to be true. A reply that promises a moderator and drops the message into a channel nobody watches is a broken button. Before you ship /ask, decide who reads the queue and what "soon" means in your actual week. You do not need a published response-time guarantee. You do need a person whose name is on the list.
Send the human enough context to answer without making the member repeat themselves. The command they ran, the channel, and the time are usually enough. A dump of the whole server is not a favor. It hides the question.
If the bot cannot tell a command-shaped question from a messy one, fail toward the person. A wrong automated answer in public trains the room to ignore the bot. A short "a moderator can see this" costs less than a confident mistake.
Keep an owner after launch
Bots rot when the token lives on one laptop and the command list lives in a scroll of old messages. Write the surface down somewhere the next person can open: the command name, who can run it, what it reads, what it writes, and the exact failure reply.
When the product changes, change the bot in the same pass. A /status line that describes last quarter's plans will teach the community to dismiss you. That is the same defect as a homepage that still sells an offer you retired.
Test the unhappy paths before you invite the server in. Remove the bot's permission and see what a member sees. Send a command with a missing argument. Run the same command twice. The second run should say what already happened, not create a second request. If a double submit files two applications, you have a bug, not a charming quirk.
Add a command only after the previous one is used without a moderator translating it in plain speech. Start with the one job the server needed this month. Ship the help line and the human path with it. A small surface you can explain is a product. A large one you have to apologize for is a chore.
If a community bot is part of the work, Hanabi's services include that kind of specific automation alongside the site and the interface. The fit is a known group and a short list of commands, not a promise to automate the community itself.
A different room has different rules. What a Telegram bot is good for is the next piece if the audience is a team or a client list rather than a public server. The command discipline is similar. The social stakes are not.
Frequently asked questions
Where should a Discord bot for a community live?
Put it in the server people already use for announcements and support. The bot belongs there when the job is something that room already repeats. It should not try to become the product for people who have not asked to work inside chat.
How many commands should the bot have?
Start with the one job the server needed this month, and keep the list small enough to remember. Each reply should say what happened, what happens next, and what to do if it is wrong. Help text belongs in the first few lines, not in a manual nobody will read.
When should the bot hand off to a person?
Hand off when the question is not a command: a billing dispute, an appeal, or anything that looks wrong. The reply should open a path a person actually watches, such as a private thread or a named role. A promise of help that lands in an unwatched channel is a broken button.
Sources and further reading
- How Long Do Users Stay on Web Pages?, Nielsen Norman Group
Written by
Hanabi
Hanabi is a product design and web development studio. The studio writes about clear websites, brand systems, and product interfaces for founders.
