Writing
How to automate Discord support with an AI bot
Turn support questions into documentation, set your bot's rules, and test AI Discord support before enabling it for your community.
If you run a community for your product or service on Discord, support may happen alongside everything else. Members share what they’re building, report problems, and ask how your product works.
Your team has to spot the questions and work out who needs to answer.
An AI Discord support bot can answer questions from your documentation while your team is offline. You decide where it should respond, which sources it can use, and when a person should take over.
Whether you plan to run this bot in-house or buy one off the shelf, this guide goes over what’s involved in automating your Discord support with an AI bot.
1. Collect your support questions
Start with recent support conversations. What do people ask, and how does your team answer? Gather those question-and-answer pairs, along with any documentation your team links to.
You can use a spreadsheet to keep these together, with columns for the question, answer, source, and notes. Use the notes to say what you like about an answer and what you’d change.
If you use an agent like Claude, Codex, or OpenCode, you can give it a connection to Discord or an export of your conversations to help. Ask it to find questions and answers, group similar questions, and keep links to the original messages. If you use a separate support tool, those conversations can also help you work out what your Discord bot should know how to answer.
Here is an example entry, using the sample documentation for Relayboard, a fictional project tool:
| Field | Example |
|---|---|
| Question | Can I turn off email notifications but still get updates in the app? |
| Answer | Open Settings → Notifications and turn off Email updates. In-app notifications stay on. |
| Source | Notifications documentation |
| Notes | Explains what stays on. Could also say whether it affects anyone else’s settings. |
Keep follow-up questions too. They can show you what the first answer missed. These examples give you something to build from and a way to try out a bot, including one you’re thinking of buying.
2. Prepare your documentation
Once you’ve organized the questions, look at the answers and sources you’ve collected. Do your docs cover those questions? Or are some answers knowledge that lives in your team’s heads and support conversations?
This is where you might need to spend some time on documentation. Work out what you already have, what needs updating, and what you need to write down.
An agent can help here too. Give it access to your existing docs and past support answers, then ask it to draft documentation for the gaps. Include information about your current product so it has what it needs to write those answers.
3. Set your bot’s rules
Next, decide how you want the bot to behave. Where should it reply? Should it answer every support question or wait until someone mentions it?
Your answers will shape what you build or buy. Check what a vendor supports: a bot limited to one channel or replies to mentions may not fit how you want to handle support.
Tell it which sources to use, whether to link to them, and what to do when it doesn’t know the answer. Also decide when it should bring in your team and who should receive the question.
If you’re building with an agent that supports skills, you can put these rules into a skill: a set of instructions for a task. Our OpenCode skills guide shows how to create one. The same approach to writing clear instructions applies to Claude, Codex, and other agents.
Here’s a bare-bones instruction template you can build on, or use as the starting point for your own support skill:
Reply in [support channel] when someone mentions you.
Answer from [approved documentation] and link to the source.
Ask a follow-up if you need more information.
If the docs don't cover the question, say so and use [support route].
Send requests that need an account check to [support route].
Do not request passwords or payment details in Discord.
Stop responding when a support team member takes over.
Replace the brackets with your own channel, docs, and process for reaching your team. Make sure the tool you choose can follow those rules, including sending the question to a person.
4. Build or choose your bot
With your questions, docs, and rules in place, you can decide how to run the bot.
If you’re building it yourself, choose an agent framework and somewhere to host it. You’ll also need a Discord connection that passes messages to the agent and sends its answers back.
For our support demo, we use OpenCode to run the support skill and Cloudflare to host the work. The skill and its sources give the agent the instructions and product knowledge for each setup.
You can also hand off the setup and ongoing management. If that’s the route you want, talk to us about Discord support.
Whatever route you choose, including an off-the-shelf bot, check it against the requirements you’ve written down. Can it use your sources, answer where you want it to, and bring in your team when needed?
5. Try it out
Go back to the support questions you collected and try a few scenarios:
- A question it should answer. Does it give the right answer from your docs? Try a follow-up too.
- A question your docs don’t cover. Does it say it doesn’t know, ask for more information, or make something up?
- A question it should pass to your team. Does it follow the process you chose? Check that the right person receives it and can take over without the bot continuing to reply.
If something goes wrong, check whether you need to change the docs, the rules, or the connection. Then try again before letting it answer customers.
6. Keep your bot up to date
Whether you run the bot yourself or pay someone else to manage it, someone will need to make sure it keeps working for your team. Decide who that is before you turn it on. Agree on who receives support questions that need a person, too. That can be the same person or someone else on your team.
Building or buying the bot still leaves ongoing work: maintaining the documentation and improving its answers as your product evolves. Make sure someone owns that work, whether it’s you, a teammate, or a provider.
If you’d rather hand off setup and ongoing management, talk to us about our managed Discord support.
Skip to content