待翻译:AI Discord Ticket Bot: Answer First, Then Escalate (No Code)
AI 服务暂时不可用,以下为来源摘要,待恢复后补全翻译:AI Discord Ticket Bot: Answer First, Then Escalate (No Code) Piotr Grudzień on August 4, 2026 • 26 min read ; the original PNG/JPG stays as the fallback and remains the og:image for social scrapers. --> Quickchat AI ans…
AI 服务暂时不可用,以下为来源正文,待恢复后补全翻译。
AI Discord Ticket Bot: Answer First, Then Escalate (No Code) Piotr Grudzień on August 4, 2026 • 26 min read ; the original PNG/JPG stays as the fallback and remains the og:image for social scrapers. --> Quickchat AI answers support questions in your Discord server from your own documentation, and opens a private ticket thread only when it cannot. This guide builds that bot end to end, with no code, in about half an hour. The result behaves like a good first-line agent. A member asks how to reset an API key and gets the real steps in the channel. A member asks something the docs do not cover, and instead of guessing, the bot says so, opens a private thread, pulls the member into it, pings your support role with a one-line summary, and hands the conversation to a human who can answer from your Inbox. You need two things, both free: a Quickchat AI Agent (sign up here and use it for free) a Discord server where you are an admin The screenshots below come from a test Agent called Lumen, the support bot for a fictional product-analytics company called Beacon. The company is invented so the example stays neutral, but every conversation, every API call and every ticket thread shown here was produced by a real Agent running the real reply pipeline against a real Discord server. What you will build One decision per question. On the happy path nothing at all is written to Discord. Three AI Actions do the escalation work, and Quickchat AI installs all three from one gallery card: StepWhat happensDiscord call A member asks a covered questionThe Agent answers in the channel from your knowledge basenone A member asks an uncovered questionThe Agent says plainly that it does not have thatnone … then it opens a ticketA private thread appears in your ticket channelPOST channel threads … then it adds the memberThe person who asked is pulled into the threadPUT thread members … then it pages your teamThe thread pings your support role with a summaryPOST thread message A human takes overThe conversation is flagged in your Inbox, and their reply goes back to DiscordHuman Handoff What is a knowledge base, and why does it set your ticket volume? If you have not built an AI Agent before, this is the one concept worth two minutes. A knowledge base is your own documentation, loaded into your Agent and indexed so it can be searched during a conversation. You can point Quickchat AI at your help-docs URL and let it scrape the pages, paste articles in by hand, or upload files. At reply time the Agent searches it and answers from what it finds, rather than from whatever the underlying model happens to remember about the world. If you are starting from nothing, how to build a chatbot knowledge base covers what to write and in what order. Everything your docs cover gets answered. Everything they do not becomes a ticket. That is the whole lever for this build. Deflection is not a prompt trick and it is not a model capability: it is your coverage. If the bot escalates more than you expected, the tickets are telling you which pages you have not written yet. Illustrative rather than measured. The point is the direction: writing docs is the highest-leverage thing you can do here. Can an AI actually answer support questions in Discord? For the questions your docs cover, yes, and with the real steps rather than a paraphrase. Here is the deflection case from the test server, unedited: Answered in the channel, from the knowledge base article. No ticket was created, because none was needed. The more interesting half is what happens when the answer is not there. The bot says so: The honest failure. Beacon’s knowledge base deliberately omits enterprise SSO, so this is the path that opens a ticket. An Agent that invents a plausible SSO procedure is worse than one that opens a ticket, so this behaviour is worth deliberately testing rather than hoping for. We come back to it in testing. Two ways to connect Discord, and why tickets need the second Quickchat AI has two Discord connections, and the difference matters before you start. Both answer questions in your server. Only one can run AI Actions. One-click is the fast path. In External Apps you open Discord, click Add to your Discord server, authorize it, and the shared Quickchat AI bot is live in your server in about a minute. It answers when members @mention it or use /ask, and for a lot of servers that is the whole job. You do get to name it. Before you authorize, there is a Bot name in the new server field, prefilled with your Agent’s name, and every connected server keeps its own Bot name in this server box you can change later. It is a Discord nickname, so it is per server and capped at 32 characters, and clearing it puts the bot back to Quickchat AI. What stays shared is the avatar and the underlying @username, because one Discord application is serving every server that installs it. One-click does not mean generic. The bot carries your Agent’s name into the server, and you can change it per server afterwards. Advanced setup registers your own Discord application. You create a bot in Discord’s developer portal and paste its token into Quickchat AI once. It takes about ten minutes and it gets you your own avatar and @username, direct messages, several bots in one server, and the thing this guide needs: AI Actions. The reason is worth stating plainly rather than treating as a quirk. An AI Action calls the Discord API as your bot, using a credential Quickchat AI injects into the request at send time. The shared one-click bot’s token belongs to the shared bot, not to you, so it is not available for your Actions to send. If you open the Discord gallery without your own app connected, it tells you so and disables the cards rather than letting you build something that cannot run. External Apps is where both paths start. Advanced setup lives in a callout at the bottom of the Discord panel. What you need before you start Connect your own Discord app. In External Apps, open Discord, find Use your own Discord app and choose Advanced setup. Create the application and bot in Discord’s developer portal, turn the Message Content Intent on, leave Require OAuth2 Code Grant off, and paste the bot token. Quickchat AI validates it as you type. The Create an AI Discord bot guide covers the portal side in detail if you have not done it before. Grant the bot only what a support bot needs. On the ticket channel: View Channels, Send Messages, Read Message History, Create Private Threads, Send Messages in Threads, and Manage Threads. It needs no Kick, Ban or Timeout permission, and deliberately holds none in the test server. A support bot has no reason to moderate, and a permission it does not hold is one you never have to reason about. In Discord, create the two things the Actions will point at. This part happens in the Discord client, not in Quickchat AI, and it is the only setup you do there: A channel where tickets will open. Any text channel will do. Use the + next to your channel list, or reuse one you have. In the test server it is #support. A role to page when a ticket opens. Server Settings, then Roles, then Create Role. In the test server it is @support. Three places, and only one of them is public. Both of these come back in Step 3. When you install the ticket template, Quickchat AI reads your server live from Discord and shows you three dropdowns, one of them a Role picker listing the roles it found. You choose your support role there rather than typing an ID anywhere. The Role picker in Step 3. It reads the list from Discord, so a role you create now appears here in a moment. One detail that will bite you if you skip it: that picker only lists roles Discord reports as mentionable, and it leaves out @everyone. If your support role is not set mentionable, it simply will not appear in the dropdown, with nothing explaining why. The filter is deliberate, because the template’s whole job is to ping that role. Set it while you are creating the role and you never meet the problem: Server Settings, Roles, pick your support role, and turn this on under Display. Without it the role never reaches the picker. How does the bot decide to answer or open a ticket? Most Discord ticket bots do not decide anything. Ticket Tool, TicketsBot and the rest post a pinned panel with a Create Ticket button, or register a slash command. A member clicks it, a ticket opens, and your team reads it. That is a fine design and it is completely predictable, but it means the ten people who all asked how to reset an API key this week produced ten tickets. The same ten questions. The difference is what your team ends up reading. An answer-first bot reads your docs before it decides. And when it does escalate, opening one ticket takes exactly four facts: which channel the thread opens in which server the question came from who is asking, so they can be pulled into the thread what the ticket is called, and a one-line summary of the problem The interesting part is that those four arrive in three completely different ways, and only the last one is written by the AI: You never type a Discord ID, and the model never sees your channel or your role. The ones you pick once. Your ticket channel and your support role. You choose them from dropdowns when you install the template, and Quickchat AI bakes them into the Action. The model never sees them and cannot change them. The ones Discord supplies. With every message it forwards, the Discord integration tells Quickchat AI which server it came from and who is speaking, as {{metadata_discord_guild_id}} and {{metadata_discord_author_id}}. Your bot token arrives the same way, as a System Token injected at send time and redacted everywhere a call is logged. None of it is typed by the model, and none of it can be supplied by a public chat or API message. The ones the Agent writes. The ticket subject and the one-line issue summary. These are the only judgment calls in the entire build, which is why tuning later is short. Step 1: Create the Agent and give it a knowledge base Create your Agent, then open Knowledge Base and add your documentation. Paste your help-docs URL and let Quickchat AI scrape it, or write articles directly. Create an AI support agent from your documentation covers the scraping path in detail. Beacon’s knowledge base: resetting an API key, an empty dashboard, installing the tracking snippet, plans and billing, and exporting data. Beacon’s docs deliberately do not cover one thing: enterprise SSO setup. That gap is not an oversight in this tutorial, it is the point. Every support knowledge base has questions it does not answer, and the entire value of this bot is what it does when it hits one. SSO is that question throughout this guide. Members reach the Agent by @mentioning it in a channel it can see, or with the /ask command. There is nothing to register. Step 2: Tell the Agent when to answer and when to escalate The Agent’s instructions go in the AI Main Prompt on Identity. Paste this, adapted to your company: You are Lumen, the support assistant for Beacon, a hosted product-analytics tool for software teams. You answer questions from customers in the Beacon community Discord. Answer from your Knowledge Base whenever you can. Keep answers short and practical, two or three sentences, and give the concrete steps. If a question is not covered by your Knowledge Base, do not guess and do not invent steps. Say plainly that you do not have that information, then open a support ticket: 1. Call open_support_ticket once, with a short 2 to 4 word ticket_subject describing the problem. 2. Then call add_ticket_requester to bring the customer into the thread. 3. Then call post_in_ticket with a one line issue_summary of what the customer asked. Then tell the customer their ticket is open and the team will follow up in the new thread. Never ask the customer for their Disco [truncated for AI cost control]