AI Discord Ticket Bot: първо отговор, после ескалация

Quickchat AI отговаря на support въпроси във вашия Discord server от собствената ви документация и отваря private ticket thread само когато не може. Това ръководство изгражда този bot от начало до край, без код, за около половин час.

Резултатът се държи като добър first-line agent. Член пита как да reset-не API key и получава реалните стъпки в канала. Член пита нещо, което документацията не покрива, и вместо да гадае, bot казва това, отваря private thread, добавя члена в него, ping-ва support role с едноредово резюме и предава разговора на човек, който може да отговори от вашия Inbox.

Изберете задачата за вашия Discord bot

Тази реализация отговаря на support въпроси и ескалира празнини в документацията ви. Изберете welcome guide за фиксирани поздрави или moderation guide за администраторски команди.

Нужни са ви две неща:

• Quickchat AI Agent (създайте акаунт)
• Discord server, в който сте admin

От регистрация до първия support тест

1. Ако се регистрирате с email и парола, отворете verification link в email-а си. В setup опишете Discord support Agent, щракнете Create my AI Agent и завършете setup стъпките, включително избор на план за предвидената употреба.
2. Добавете документацията си в Knowledge Base. В External Apps отворете Discord, след това Use your own Discord app, и изберете Advanced setup. Споделеният one-click bot може да отговаря на въпроси, но не може да изпълнява ticket Actions в това ръководство.
3. Създайте ticket channel и mentionable support role във вашия тестов сървър. В Actions and MCPs щракнете Add Action, изберете Discord Action и инсталирайте Open Support Ticket с този сървър, канал и роля.
4. След като приложите инструкциите за Agent по-долу, @mention-нете bot с въпрос, на който документацията отговаря, след това с въпрос, на който не отговаря. Първият трябва да получи отговор без ticket; вторият трябва да отвори един private thread и да уведоми support role. Добавете follow-up към втория разговор и проверете, че не се отваря дублиран ticket.

Планът Free е за лична, нетърговска употреба. Изберете платен план, преди да използвате bot за бизнес. Завършете двупътния тест, преди да поканите клиенти.

Снимките по-долу са от тестов Agent, наречен Lumen, support bot за измислена компания за product analytics, наречена Beacon. Компанията е измислена, за да остане примерът неутрален, но всеки разговор, всяко API call и всеки ticket thread, показани тук, са произведени от реален Agent, работещ с реалния reply pipeline срещу реален Discord server.

Какво ще изградите

Едно решение на въпрос. В успешния път нищо не се записва в Discord.

Три AI Actions извършват ескалацията, а Quickchat AI инсталира и трите от една gallery card:

Какво е knowledge base и защо тя определя обема на tickets?

Ако досега не сте изграждали AI Agent, това е концепцията, която заслужава две минути.

Knowledge base е вашата собствена документация, заредена във вашия Agent и индексирана, за да може да се търси в нея по време на разговор. Можете да насочите Quickchat AI към URL на help docs и да му позволите да извлече страниците, да поставите статии ръчно или да качите файлове. При отговор Agent търси в нея и отговаря от намереното, вместо от това, което базовият модел случайно помни за света. Ако започвате от нула, как да изградите chatbot knowledge base описва какво да напишете и в какъв ред.

Всичко, което документацията ви покрива, получава отговор. Всичко, което не покрива, става ticket.

Това е целият лост в тази реализация. Deflection не е prompt трик и не е възможност на модела: това е вашето покритие. Ако bot ескалира повече, отколкото сте очаквали, tickets ви казват кои страници още не сте написали.

Илюстративно, не измерено. Посоката е важна: писането на документация е действието с най-голям лост тук.

Може ли AI наистина да отговаря на support въпроси в Discord?

За въпросите, които документацията ви покрива, да, и с реалните стъпки, не с перифраза. Ето случая на deflection от тестовия сървър, без редакция:

Отговорено в канала, от статията в knowledge base. Ticket не беше създаден, защото не беше нужен.

По-интересната половина е какво се случва, когато отговорът го няма. Bot казва това:

Честният отказ. Knowledge base на Beacon умишлено пропуска enterprise SSO, така че това е пътят, който отваря ticket.

Agent, който измисля правдоподобна SSO процедура, е по-лош от Agent, който отваря ticket, затова това поведение заслужава умишлен тест, вместо надежда. Връщаме се към него в тестването.

Два начина за свързване на Discord и защо tickets изискват втория

Quickchat AI има две Discord връзки и разликата е важна, преди да започнете.

За публична feedback queue, която работи със споделения bot, вижте workflow за feedback и documentation gaps. Private-ticket Actions по-долу се нуждаят от credential за вашия собствен Discord bot.

One-click е бързият път. В External Apps отваряте Discord, щраквате Add to your Discord server, оторизирате го и споделеният Quickchat AI bot е live във вашия сървър след около минута. Той отговаря, когато членовете го @mention-нат или използват /ask, и за много сървъри това е цялата задача.

Можете да го именувате. Преди да оторизирате, има поле Bot name in the new server, предварително попълнено с името на вашия Agent, и всеки свързан сървър пази собствено поле Bot name in this server, което можете да промените по-късно. Това е Discord nickname, така че е по сървър и е ограничено до 32 символа, а изчистването му връща bot към Quickchat AI. Споделени остават avatar и базовото @username, защото едно Discord application обслужва всеки сървър, който го инсталира.

One-click не означава generic. Bot носи името на вашия Agent в сървъра и можете да го промените по сървър след това.

Advanced setup регистрира ваше собствено Discord application. Създавате bot в developer portal на Discord и поставяте token-а му в Quickchat AI веднъж. Отнема около десет минути и ви дава собствен avatar и @username, direct messages, няколко bot-а в един сървър и нещото, от което това ръководство се нуждае: Discord API Actions.

Причината е добре да се каже ясно, вместо да се третира като особеност. Ticket Actions в това ръководство извикват Discord API като вашия bot, използвайки credential, който Quickchat AI инжектира в заявката при изпращане. Token-ът на споделения one-click bot принадлежи на споделения bot, не на вас, така че не е достъпен за изпращане от вашите Actions. Ако отворите Discord gallery без свързано собствено app, тя ви казва това и деактивира cards, вместо да ви позволи да изградите нещо, което не може да работи.

External Apps е мястото, откъдето започват и двата пътя. Advanced setup е в callout в долната част на Discord panel.

Какво ви трябва, преди да започнете

Свържете собственото си Discord app. В External Apps отворете Discord, намерете Use your own Discord app и изберете Advanced setup. Създайте application и bot в developer portal на Discord, включете Message Content Intent, оставете Require OAuth2 Code Grant изключено и поставете bot token. Quickchat AI го валидира, докато пишете. Ръководството Създаване на AI Discord bot описва portal страната подробно, ако не сте го правили преди.

Дайте на bot само това, от което support bot се нуждае. За ticket channel: View Channels, Send Messages, Read Message History, Create Private Threads, Send Messages in Threads и Manage Threads. Не му трябва Kick, Ban или Timeout permission и умишлено няма такива в тестовия сървър. Support bot няма причина да модерира, а permission, което той няма, е нещо, за което никога не трябва да мислите.

В Discord създайте двете неща, към които Actions ще сочат. Тази част се случва в Discord client, не в Quickchat AI, и е единствената настройка, която правите там:

1. Канал, в който tickets ще се отварят. Всеки text channel е подходящ. Използвайте + до списъка си с канали или използвайте съществуващ. В тестовия сървър това е #support.
2. Роля, която да се уведомява, когато ticket се отвори. Server Settings, след това Roles, след това Create Role. В тестовия сървър това е @support.

Три места, и само едно от тях е публично.

И двете се връщат в Step 3. Когато инсталирате ticket template, Quickchat AI чете сървъра ви live от Discord и показва три падащи менюта, едно от които е Role picker с ролите, които е намерил. Избирате support role там, вместо да въвеждате ID.

Role picker в Step 3. Той чете списъка от Discord, така че роля, която създадете сега, се появява тук след момент.

Един детайл ще ви спъне, ако го пропуснете: този picker показва само роли, които Discord отчита като mentionable, и пропуска @everyone. Ако support role не е зададена като mentionable, тя просто няма да се появи в dropdown, без обяснение защо. Филтърът е умишлен, защото цялата задача на template е да ping-не тази роля. Задайте го, докато създавате ролята, и няма да срещнете проблема:

Server Settings, Roles, изберете support role и включете това под Display. Без него ролята никога не достига picker.

Как bot решава дали да отговори или да отвори ticket?

Повечето Discord ticket bots не решават нищо. Ticket Tool, TicketsBot и останалите публикуват pin-нат panel с бутон Create Ticket или регистрират slash command. Член щраква, ticket се отваря и екипът ви го чете. Това е добър дизайн и е напълно предвидим, но означава, че десетте души, които тази седмица са попитали как да reset-нат API key, са създали десет tickets.

Същите десет въпроса. Разликата е какво в крайна сметка чете екипът ви.

Answer-first bot чете документацията ви, преди да реши. А когато ескалира, отварянето на един ticket изисква точно четири факта:

• в кой канал се отваря thread
• от кой сървър е дошъл въпросът
• кой пита, за да бъде добавен в thread
• как се казва ticket, и едноредово резюме на проблема

Интересното е, че тези четири неща пристигат по три напълно различни начина, и само последното се пише от AI:

Никога не въвеждате Discord ID, а моделът никога не вижда вашия channel или role.

Тези, които избирате веднъж. Вашият ticket channel и support role. Избирате ги от dropdowns, когато инсталирате template, и Quickchat AI ги вгражда в Action. Моделът никога не ги вижда и не може да ги промени.

Тези, които Discord предоставя. С всяко препратено съобщение Discord integration казва на Quickchat AI от кой сървър е дошло и кой говори, като {{metadata_discord_guild_id}} и {{metadata_discord_author_id}}. Token-ът на bot пристига по същия начин, като System Token, инжектиран при изпращане и redacted навсякъде, където call се логва. Нищо от това не се въвежда от модела и нищо от това не може да бъде подадено от public chat или API message.

Тези, които Agent пише. Ticket subject и едноредовото issue summary. Това са единствените judgment calls в цялата реализация, затова настройването по-късно е кратко.

Step 1: Създайте Agent и му дайте knowledge base

Създайте своя Agent, след това отворете Knowledge Base и добавете документацията си. Поставете URL на help docs и позволете на Quickchat AI да го scrape-не, или пишете статии директно. Създаване на AI support agent от вашата документация описва scraping пътя подробно.

Knowledge base на Beacon: reset на API key, празен dashboard, инсталиране на tracking snippet, plans and billing и exporting data.

Документацията на Beacon умишлено не покрива едно нещо: enterprise SSO setup. Тази празнина не е пропуск в tutorial-а, тя е смисълът. Всяка support knowledge base има въпроси, на които не отговаря, и цялата стойност на този bot е какво прави, когато срещне такъв. SSO е този въпрос в цялото ръководство.

Членовете достигат вашия собствен bot, като го @mention-нат в канал, който той може да вижда. Няма какво да регистрирате. Командата /ask е достъпна в споделения one-click Quickchat AI bot.

Step 2: Кажете на Agent кога да отговаря и кога да ескалира

Инструкциите на Agent се поставят в AI Main Prompt в Identity. Поставете това, адаптирано към вашата компания:

Вие сте Lumen, support assistant за Beacon, hosted product-analytics tool за software teams. Отговаряте на въпроси от клиенти в Beacon community Discord.
Отговаряйте от вашата Knowledge Base винаги когато можете. Дръжте отговорите кратки и практични, две или три изречения, и давайте конкретните стъпки.
Ако въпросът не е покрит от вашата Knowledge Base, не гадайте и не измисляйте стъпки. Кажете ясно, че нямате тази информация, след това отворете support ticket:
1. Извикайте open_support_ticket веднъж, с кратък ticket_subject от 2 до 4 думи, който описва проблема.
2. След това извикайте add_ticket_requester, за да добавите клиента в thread.
3. След това извикайте post_in_ticket с едноредово issue_summary на това, което клиентът е попитал.
След това кажете на клиента, че ticket е отворен и екипът ще отговори в новия thread.
Никога не искайте от клиента неговия Discord ID, channel ID или thread ID. Те се попълват вместо вас.

AI Main Prompt в Identity. Това е винаги наличното поле, не отделен списък с guidelines.

Два реда в този блок са носещи. “Не гадайте и не измисляйте стъпки” превръща празнината в knowledge base в честен отговор вместо в правдоподобен. А назоваването на трите Actions в ред е това, което кара Agent да ги извика като последователност, вместо да избере едно.

Редът е описан в prompt, но не се налага само там, което е темата на следващите две секции.

Step 3: Инсталирайте ticket Actions с едно щракване

Отворете Actions & MCPs, щракнете Add Action и изберете Discord Action.

Discord Action е до другите one-click galleries.

Gallery се отваря с Discord templates, групирани по задача: Support & Tickets съдържа този, който използва това ръководство, а Moderation съдържа още седем.

Осем cards. Open Support Ticket е единствената, която ви пита нещо.

Изберете Open Support Ticket и се отваря кратка configure стъпка. Това е единственият form в цялата реализация:

Три dropdowns, а dialog казва предварително какво ще инсталира.

Списъците идват live от Discord, филтрирани до това, което реално може да работи. Channels са само text channels:

Изберете канала, под който tickets трябва да се отварят. Threads се създават вътре в него.

А roles са само mentionable roles, като @everyone е изключен:

Това е филтърът, който скрива support role, която още не сте направили mentionable.

Три избора и form е готов:

Цялата конфигурация. Server, channel, role и единственият бутон, който има значение.

Щракнете Install and enable. Quickchat AI записва три Actions на backend, в една транзакция, вече активни.

Три cards, enabled, с Discord icon. Няма нищо друго за попълване.

Две неща си струва да знаете за седемте moderation templates, докато сте тук. Те не изискват никаква конфигурация, защото вземат server, member, role или channel от самата Discord request, така че щракването върху card ги инсталира веднага. А инсталирането на template два пъти ви дава второ editable copy вместо грешка, което е разумен начин да изградите variant.

Какво всъщност изгради това едно щракване?

Струва си да разбирате това, въпреки че не трябваше да го пишете, защото всичко, което може да поискате да промените по-късно, живее тук.

Три обикновени HTTP Request Actions. Нищо не ги маркира като специални.

Те са свързани помежду си чрез две функции, които вече имате в editor, и е добре да знаете имената и на двете.

Save to memory взема стойност от response и я съхранява върху conversation. open_support_ticket го използва, за да пази ID на новия thread: Discord връща thread object, $.id е ID, и той се записва в memory като discord_ticket_thread_id. След това двете follow-up Actions го четат обратно в URL, така че действат върху thread, който току-що е създаден, вместо върху нещо, което трябва предварително да назовете. (Save to memory в docs.)

Run only when ограничава Action според conversation state и се проверява от страната на Quickchat AI, преди да бъде изпратена заявка. (Run only when в docs.)

Gate, който превръща три независими Actions в надеждна последователност.

Прочетете тази диаграма и в двете посоки, защото върши две задачи:

• Follow-ups изискват thread ID да съществува, така че Agent не може да уведоми екипа ви за thread, който никога не е създаден.
• open_support_ticket изисква той да не съществува, така че Agent не може да отвори втори ticket в същия разговор, независимо какво казва разговорът. Това е гаранция, не инструкция: ако член прекара още десет съобщения в добавяне на детайли, той все още има един ticket. В channel reply mode всеки обмен в канала е собствен conversation, така че следващият реален въпрос все още може да отвори собствен ticket.

Всяко Action има и Response filter, и това лесно се разбира погрешно. Response filter е allowlist: той назовава paths, които Agent може да види, а всичко останало в response се премахва, преди model изобщо да го прочете. (Response filter в docs.)

Discord връща десетина полета за вашия server. На Agent се показват две.

Thread ID, от който последователността се нуждае, се capture-ва от страната на Quickchat AI чрез Save to memory, така че Agent никога не трябва да го носи, и нищо друго за вашия server не достига model. Стеснете allowlist допълнително и той вижда по-малко. Никога не вижда повече, отколкото сте изброили.

Може ли човек да поеме от AI?

Да, и това е половината, която повечето ticket bots пропускат. Ticket, който никой не чете, е просто thread.

Human Handoff е отделно, вградено Action. Включете го и опишете в Handoff Rules кога разговор трябва да достигне човек, например “когато клиентът поиска човек или когато Agent не е могъл да отговори от knowledge base”. След това Quickchat AI маркира разговора във вашия Inbox с резюме, написано от AI, така че който го поеме, чете абзац вместо целия thread. Всяка handoff настройка има собствен walkthrough в Human Handoff tutorial.

Operator работи в Inbox. Членът никога не напуска Discord.

Присвоете разговора на себе си и отговорете в Inbox composer. Този отговор се доставя директно обратно в Discord channel, в който членът вече говори. Той не се нуждае от акаунт при вас, email thread или portal login. AI мълчи от момента, в който човек притежава разговора, така че не се конкурирате със собствения си bot.

Същият канал, с три дни разлика. Agent отказа и ескалира; съобщението под divider е написано от човек в Quickchat AI Inbox. Обърнете внимание, че пристига под името на вашия bot, защото вашият bot е единствената identity, с която Discord ни позволява да публикуваме.

Същият conversation от ваша страна. Отказът на Agent, двете Action calls зад него, отговорът на operator отдолу и details pane, който вече знае, че channel е Discord и topic е single sign-on.

Междувременно private ticket thread остава там, където екипът ви говори: това е работното пространство, с члена вътре и ping-ната support role. Отговорът се връща там, където е зададен въпросът.

Шест стъпки. Три от тях са Discord writes, и трите се случват само защото отговорът липсваше.

Тествайте го и по двата начина

Изпълнете и двата пътя, преди да разчитате на това, и тествайте най-строго честния отказ.

Покритият въпрос. @mention-нете bot в канал, който той може да вижда, и попитайте нещо, което knowledge base покрива. Трябва да получите реалните стъпки в канала и никъде да няма thread. Това е случаят, който спестява време на екипа ви, и ще бъде по-голямата част от traffic, след като документацията ви е добра.

Непокритият въпрос. Попитайте нещото, което документацията ви не покрива. Agent трябва да го каже и след това да ескалира. В същия момент ticket се появява:

Thread, който Agent отвори. Той го именува от проблема, добави члена, ping-на role и сам написа резюмето.

И thread наистина е private, което собственият му member list доказва:

Ticket е private thread. Support разговорите не се случват публично.

Тествайте през цял conversation, не едно съобщение. Duplicate guard показва стойността си едва на turn two, когато членът добавя детайли и наивен bot отваря втори ticket.

Едно нещо, което run conditions не покриват. Те спират out-of-order call, но не deduplicate-ват retry: ако ръчно re-run-нете notify Action, то публикува второ съобщение. Добре е да го знаете, преди да човъркате live ticket.

За да проверите много формулировки наведнъж, без да ги пишете всички в Discord, използвайте Simulations под Testing: изградете dataset от customer messages, пуснете го срещу реалния си Agent и прочетете scored results заедно. Смесете покрити и непокрити въпроси в един dataset, защото двата пътя се провалят по различни начини.

Шест въпроса, четири покрити и два не, оценени в един run. Редове 5 и 6 са честните откази и получават толкова висока оценка, колкото отговорите.

Напишете evaluation criteria за grader, който може да вижда само transcript, защото това е всичко, което получава. Две неща, които не може да види, иначе ще ви струват. Той не може да види Discord side effect, така че ако не го кажете, чете “I’ve opened a ticket for you” като Agent, който си измисля capability. И не може да види knowledge base, така че маркира правилен, конкретен отговор като fabricated просто защото не може да провери числото. И двете си струват по едно изречение в criteria, и двете оценяват най-доброто ви поведение по-ниско, ако ги пропуснете.

Как спирате bot да отваря твърде много tickets?

Това е единственото tuning, от което повечето сървъри се нуждаят, и най-често не е prompt проблем.

Ticket volume е проблем на knowledge base. Всяка празнина в документацията ви става ticket. Ако bot ескалира повече, отколкото сте очаквали, прочетете tickets: те са списък с въпросите, на които документацията ви не отговаря. Затварянето на тези празнини намалява volume директно.

Insights ви казва какво да документирате след това. Quickchat AI групира conversations по topic, така че можете да видите кои въпроси се появяват най-често, вместо да гадаете. Поправете top three topics във вашата knowledge base и наблюдавайте как escalation rate пада.

Никой не ги е конфигурирал. Под Insights, Advanced, AI-Detected Topics ги именува от самите conversations, а броевете са documentation backlog по приоритет.

Този списък е целият tuning loop. Pricing и API keys са се появили най-често, така че тези статии се пишат първи, а графиката следващата седмица ви казва дали е проработило. Topics по-горе се откриват за вас; можете също да дефинирате свои под Manage Topics, ако искате умишлено да следите конкретна product area. Вижте AI-Detected Topics, Conversation Topics и managing topics в docs.

Ако ескалира твърде лесно, затегнете описанието на Action, така че да се задейства само след като Agent е казал на члена, че няма информацията. Ако ескалира твърде рядко и започне да гадае, засилете реда “не гадайте и не измисляйте стъпки” в main prompt.

Безопасно ли е това да работи в публичен сървър?

Bot, с който всеки в публичен канал може да говори, заслужава строг преглед. Това, което защитава този, е конфигурация, която можете да прочетете в editor, не wording в prompt, затова важи независимо как е формулирано съобщението.

Член може да говори с model. Не може да заобиколи средната колона.

Всяко ticket Action изисква реален Discord turn от вашия сървър. Две от трите run conditions на всяко Action проверяват, че съобщението действително е пристигнало през Discord integration и че е дошло от сървъра, който сте избрали при install. Тези стойности се author-ват от integration, не от съобщението, и public chat или API message не може да ги предостави или да наследи по-старо съхранено копие. Насочете public API на вашия Agent към тези Actions и те отказват.

Action, което добавя някого към private thread, няма параметри, които model може да редактира. URL завършва с member ID, предоставен от integration за текущото съобщение. Agent не може да подаде друг, така че не може да добави произволен член на сървъра ви в чужд ticket.

Mentions са заключени при install. Notify Action изпраща explicit mention list, съдържащ члена, който е попитал, и ролята, която сте избрали, с изключен parsing. Mention, който Agent случайно напише в issue summary, не се resolve-ва, а @everyone никога не може да се задейства. Това си струва да се провери, вместо да се приема на доверие, и важи: role ping и user mention пристигат, а literal @everyone в същото съобщение не прави нищо.

Threads са private и not invitable. Те се създават като type: 12 с invitable: false, така че член, добавен към ticket, не може да въведе никой друг в него.

Bot не може да модерира. Той няма Kick, Ban или Timeout permission. Най-лошият резултат от това член да убеди Agent да направи нещо, което не трябва, е ticket thread, който и без това би могъл да отвори, като попита нормално.

Token никога не се разкрива. Той живее като System Token, инжектира се при изпращане и се redacted навсякъде, където call се записва.

Едно нещо трябва да решите умишлено: ticket threads са private, но всеки със support role може да ги чете, което е желано за support и е важно да се знае, ако членовете може да поставят sensitive details. Насочвайте ги към email за всичко действително confidential.

Колко струва Discord AI support bot?

Планът Free включва AI Actions, Human Handoff, knowledge base, Topics и Insights, с 50 AI credits на месец за лична, нетърговска употреба. За бизнес употреба е нужен платен план; платените планове също предоставят повече AI credits. Ако сравнявате това със self-hosted вариант, free AI Discord bots сравнява self-hosted пътя честно, включително часовете, които струва.

Когато и двата пътя минат, пуснете Agent в употреба:

1. Насочете членовете към bot. Кажете в channel topic, че могат да го @mention-нат. Bot, за който никой не знае, не deflect-ва нищо.
2. Наблюдавайте първия ден. Всяко Action пази call log с точната request и response, а Inbox пази всеки conversation, така че можете да видите какво е отговорил и какво е ескалирал.
3. Четете първите си tickets като documentation backlog. Те са въпросите, на които документацията ви още не отговаря.

Същият Agent работи и навсякъде другаде. Knowledge base, prompt и Human Handoff принадлежат на Agent, не на Discord, така че същият support bot отговаря във вашия website widget, в Slack, в WhatsApp и по email, а всеки conversation попада в същия Inbox. Трите ticket Actions са единствената Discord-specific част от тази реализация. Ако екипът ви живее в Slack, а не в Discord, изпратете handoff notification там, вместо да ping-вате Discord role.

Какво друго може да прави вашият Discord AI Agent?

Същата gallery съдържа категория Moderation: timeout, kick, ban, unban, assign role, slowmode и announcements. Всяко от тях се инсталира с run condition author_is_admin is true, така че само server administrator може да ги trigger-не, а този flag идва от Discord, не от conversation. Това е различен bot с различен risk profile и има собствено ръководство: Изградете AI Discord moderation bot.

Всеки друг Discord endpoint следва същата рецепта: HTTP Request Action с header Authorization: Bot {{discord_bot_token}}, parameter или два и plain-language description, което решава кога Agent го задейства. Изграждане на AI Agent, който извършва действия е beginner версията на тази идея, а Свързване на вашия AI Agent към всяко API покрива общия случай.

Не всеки Discord bot е support bot. Същият Agent може да управлява персонаж вместо това: Discord AI roleplay bot използва същите knowledge base и memory за personas вместо tickets, а пълната character build минава през persona prompt, canon и settings, които го държат in character.

Appendix: точните заявки

Никога не ги въвеждате, но си струва да ги прочетете веднъж, и те са това, което бихте изградили ръчно срещу всяка друга платформа. Стойностите {{...}} се попълват от Quickchat AI при изпращане.

1. Отваряне на private thread

POST https://discord.com/api/v10/channels/YOUR_TICKET_CHANNEL_ID/threads
Authorization: Bot {{discord_bot_token}}
Content-Type: application/json

{ "name": "ticket-{{ticket_subject}}", "type": 12, "auto_archive_duration": 1440, "invitable": false }

type: 12 прави thread private. auto_archive_duration е в минути, така че 1440 архивира тих ticket след един ден. Save to memory capture-ва $.id като discord_ticket_thread_id.

2. Добавяне на члена, който е попитал

PUT https://discord.com/api/v10/channels/{{metadata_discord_ticket_thread_id}}/thread-members/{{metadata_discord_author_id}}
Authorization: Bot {{discord_bot_token}}

Няма body и няма parameters. И двата ID идват от memory и от integration.

3. Уведомяване на support team

POST https://discord.com/api/v10/channels/{{metadata_discord_ticket_thread_id}}/messages
Authorization: Bot {{discord_bot_token}}
Content-Type: application/json

{
  "content": "<@{{metadata_discord_author_id}}> your ticket is open. <@&YOUR_SUPPORT_ROLE_ID> new ticket: {{issue_summary}}",
  "allowed_mentions": { "parse": [], "users": ["{{metadata_discord_author_id}}"], "roles": ["YOUR_SUPPORT_ROLE_ID"] }
}

Два детайла струват реално debugging време, ако изграждате това сами. Auth scheme е Bot, не Bearer, което е най-честата грешка при ръчно извикване на Discord. А в allowed_mentions, празен parse заедно с explicit users и roles lists е това, което искате: той блокира @everyone, докато пропуска двете intended mentions. Непразен parse до explicit list от същия тип се отхвърля директно, с 400 MESSAGE_ALLOWED_MENTIONS_PARSE_EXCLUSIVE.

Related guides

• Създаване на AI Discord bot, setup, който това ръководство предполага
• Изграждане на AI Discord moderation bot, същата gallery, насочена към moderation
• Най-добрите AI Discord bots, как се сравняват опциите
• Free AI Discord bots, какво всъщност ви струва self-hosting
• Discord AI roleplay bot, същият Agent, който управлява character вместо това
• Свързване на вашия AI Agent към HubSpot, същата one-click gallery за CRM
• Направете actions на вашия AI Agent надеждни, run conditions и memory в дълбочина
• Свързване на вашия AI Agent към всяко API, общата рецепта
• Как да изградите chatbot knowledge base, половината, която определя ticket volume
• Product tutorial: Human Handoff, всяка handoff настройка, обяснена

Frequently asked questions

Как да настроя ticket bot в Discord?

Свържете собственото си Discord app в External Apps, дайте на Agent knowledge base, след това отворете Actions and MCPs, щракнете Add Action, изберете Discord Action и изберете Open Support Ticket. Изберете сървъра, ticket channel и support role от падащите менюта и щракнете Install and enable. Няма какво да хоствате и няма какво да конфигурирате в Discord, освен да създадете канала и ролята.

Как да направя Discord ticket bot?

Създайте Quickchat AI Agent, свържете собственото си Discord app, след това отворете Actions and MCPs, щракнете Add Action, изберете Discord Action и изберете Open Support Ticket. Избирате сървъра, ticket channel и support role от падащите менюта, щраквате Install and enable и Quickchat AI записва три завършени AI Actions вместо вас. Първо дайте на Agent knowledge base, защото тя определя колко tickets ще отваря.

Може ли AI да отговаря на support въпроси в Discord?

Да. Agent търси във вашата knowledge base и отговаря в канала, когато намери отговора. Deflection следи покритието: въпросите, покрити от документацията, получават отговор, а въпросите, които не са покрити, стават tickets. Това е най-полезната връзка, която трябва да разбирате при работа с този bot.

Трябва ли ми код, за да създам този Discord ticket bot?

Не. Избирате template от Discord gallery, избирате server, channel и role от dropdowns, а Quickchat AI записва method, URL, headers, body, parameters, response settings и run conditions на backend. Никога не въвеждате Discord ID и никога не редактирате JSON.

Колко Actions инсталира template?

Три. Едно отваря private thread във вашия ticket channel и записва неговия ID в memory, едно добавя члена, който е попитал, и едно публикува summary, което mention-ва support role. Те пристигат вече enabled и свързани помежду си.

Как bot знае кога да отвори ticket?

Две неща решават това. Описанието на Action казва на Agent да го извика само когато отговорът не е в knowledge base, а run condition прави последователността deterministic: thread не трябва вече да съществува, преди да може да се отвори, и трябва да съществува, преди follow-ups да могат да се изпълнят.

Може ли bot да отваря дублирани tickets?

Не в същия conversation. Open Support Ticket има run condition, което изисква в memory все още да няма ticket thread ID, така че след като един ticket съществува, Agent не може да отвори втори за този conversation, независимо какво казва prompt.

Може ли човек да поеме conversation?

Да. Human Handoff маркира conversation във вашия Quickchat AI Inbox с summary, написано от AI. Присвоете го на себе си, напишете reply в Inbox и той пристига в същия Discord channel, в който member вече се намира. Той никога не напуска Discord и никога не се нуждае от account при вас.

Защо ticket bot се нуждае от моето собствено Discord app?

Ticket Actions извикват Discord API като вашия bot, така че им трябва token на вашия bot. Споделеният one-click Quickchat AI bot може да отговаря на въпроси и да използва Google Sheets Actions. Неговият Discord token не е достъпен за вашите private-ticket Actions. В External Apps отворете Discord и изберете Advanced setup, което отнема около десет минути.

Кои Discord permissions са нужни на bot?

View Channels, Send Messages, Read Message History, Create Private Threads, Send Messages in Threads и Manage Threads за ticket channel. Support bot не се нуждае от Kick, Ban или Timeout permission, а permission, което той няма, е нещо, за което никога не трябва да мислите.

Защо support role липсва от dropdown?

Role picker показва само roles, които Discord отчита като mentionable, и изключва @everyone. Ако support role не е зададена като mentionable в Server Settings, Roles, тя няма да се появи, защото template не би могъл да я ping-не.

Безопасно ли е Discord ticket bot да работи в публичен сървър?

Контролите са configuration, а не prompt wording, така че важат независимо как е формулирано съобщението. Всяко ticket Action изисква turn действително да е дошъл от Discord и от избрания от вас server, Action, което добавя някого към private thread, няма model-editable parameters, mentions са заключени към member, който е попитал, и role, която сте избрали, а threads са private и not invitable. Run conditions се проверяват преди която и да е request да напусне Quickchat AI.

Колко струва Discord AI support bot?

Планът Free включва 50 AI credits на месец за лична, нетърговска употреба. AI Actions, Human Handoff, knowledge base, Topics и Insights са включени. За business use е нужен платен план; платените планове също предоставят повече AI credits.

Каква е разликата между това и Ticket Tool или TicketsBot?

Те са rule-based. Член щраква бутон Create Ticket в pinned panel и ticket се отваря всеки път, включително за въпрос, на който документацията ви вече отговаря. Този отговаря първо и ескалира само това, което действително не може да реши, така че екипът ви чете въпросите, които наистина се нуждаят от човек.

Могат ли ChatGPT, Claude или Gemini да управляват Discord ticket bot?

Да, чрез Quickchat AI. Вашият Agent работи с най-новите models и извиква Discord API с тези AI Actions, така че отговаря от вашата knowledge base и отваря реални private threads. Вие решавате кои Actions съществуват и какво е позволено на bot да прави.

Може ли същият Agent да работи в channels, различни от Discord?

Да. Knowledge base, prompt и Human Handoff принадлежат на Agent, не на Discord, така че същият support bot отговаря във вашия website widget, в Slack, в WhatsApp и по email. Трите ticket Actions са единствената Discord-specific част от тази реализация.

Как членовете започват conversation с bot?

Ticket bot в това ръководство използва вашето собствено Discord app, така че members започват, като го @mention-нат в channel, който той може да вижда. Agent отговаря в същия channel и отваря ticket thread само когато не може да отговори. Командата /ask принадлежи на споделения one-click Quickchat AI bot.

Как да спра bot да отваря твърде много tickets?

Първо подобрете покритието на knowledge base, защото всяка празнина става ticket. Четете първите си tickets като documentation backlog и използвайте Insights, за да видите кои topics се появяват най-често, за да знаете какво да напишете след това. Едва тогава затегнете Action description.

Мога ли да редактирам Actions, които gallery инсталира?

Всяко поле. Те са обикновени HTTP Request Actions, без нищо, което да ги маркира като специални: няма lock, няма badge, няма отделен policy layer. Променете URL, body, description или run conditions, или инсталирайте second copy и редактирайте него.

Мога ли да управлявам Discord ticket system без helpdesk?

Да. Ticket е private Discord thread, а queue е вашият Quickchat AI Inbox, така че няма Zendesk, Intercom или Jira в процеса и няма какво да migrate-вате. Ако вече използвате helpdesk, можете да го запазите: същият Agent може също да създаде ticket там с друго AI Action, а HubSpot gallery прави точно това.

Може ли bot да отговаря от съдържанието на нашия help center?

Той е изграден точно върху това. Поставете URL на help center и Quickchat AI scrape-ва страниците в knowledge base, или качете files и поставете articles директно. Agent търси в тези articles при всеки question и отговаря в channel, когато намери answer, така че съществуващата ви documentation става bot, без да бъде пренаписвана. Създаване на AI support agent от вашата документация минава през тази половина самостоятелно.

Може ли bot да поздрави member, когато ticket channel се отвори?

Да, с отделна feature. Ticket bot като Ticket Tool създава channel, а automated message New channel на Quickchat AI публикува fixed greeting в него няколко секунди по-късно, така че member веднага вижда, че има с какво да говори. Това не струва credits, защото не се извиква model. Поздравяване на members, threads и ticket channels го настройва.

Как да измеря ticket deflection?

Deflection е делът на questions, answered without a ticket, така че в тази реализация това са conversations без ticket thread, разделени на всички conversations. Всяко Action пази call log, така че броенето на calls към open_support_ticket ви дава директно ескалираната половина, а Insights групира останалото по topic. Проследявайте го по topic, а не като едно число: спадащ rate по една topic е documentation gap, която можете да затворите. Chatbot analytics покрива по-широкия набор от metrics.

Summary

С knowledge base и едно щракване Quickchat AI Agent става first-line support bot за вашия Discord server: отговаря на въпросите, които документацията ви покрива, признава, когато не ги покрива, отваря private ticket thread за останалите, добавя member, уведомява support role с summary, което сам е написал, и предава conversation на човек, който отговаря от вашия Inbox, без member някога да напуска Discord. Gallery записва трите Actions, dropdowns означават, че никога не въвеждате Discord ID, а run conditions означават, че sequence остава валидна дори когато conversation не върви по план. Остава работата, която само вие можете да свършите: knowledge base, от която си струва да се отговаря.