AI Discord ticket-бот: спершу відповідає, потім ескалує

Quickchat AI відповідає на запитання підтримки у вашому Discord server з вашої власної документації та відкриває приватний ticket thread лише тоді, коли не може відповісти. Цей посібник будує такого бота від початку до кінця, без коду, приблизно за пів години.

Результат працює як хороший агент першої лінії. Учасник запитує, як скинути API key, і отримує реальні кроки в каналі. Учасник запитує те, чого немає в документації, і замість припущень бот прямо про це каже, відкриває приватний thread, додає до нього учасника, сповіщає вашу роль підтримки коротким підсумком і передає розмову людині, яка може відповісти з вашого Inbox.

Виберіть завдання для вашого Discord-бота

Ця збірка відповідає на запитання підтримки та ескалує прогалини у вашій документації. Виберіть посібник із привітань для фіксованих привітань або посібник із модерації для команд адміністратора.

Вам потрібні дві речі:

• Quickchat AI Agent (створіть обліковий запис)
• Discord server, де ви є admin

Від реєстрації до першого тесту підтримки

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 із запитанням, на яке docs відповідають, а потім із запитанням, на яке не відповідають. Перше має отримати відповідь без тікета; друге має відкрити один приватний thread і сповістити роль підтримки. Додайте follow-up до другої розмови і перевірте, що дубліката тікета не відкрито.

План Free призначений для особистого, некомерційного використання. Виберіть платний план, перш ніж використовувати бота для бізнесу. Завершіть тест із двома шляхами, перш ніж запрошувати клієнтів.

Скріншоти нижче взяті з тестового Agent на ім’я Lumen, бота підтримки для вигаданої компанії продукт-аналітики Beacon. Компанію вигадано, щоб приклад залишався нейтральним, але кожну розмову, кожен API call і кожен ticket thread, показані тут, створив реальний Agent, який працював через реальний reply pipeline із реальним Discord server.

Що ви створите

Одне рішення на запитання. У щасливому сценарії в Discord взагалі нічого не записується.

Три AI Actions виконують ескалацію, і Quickchat AI встановлює всі три з однієї картки gallery:

Що таке база знань і чому вона визначає обсяг тікетів?

Якщо ви раніше не створювали AI Agent, це єдина концепція, на яку варто витратити дві хвилини.

База знань це ваша власна документація, завантажена в Agent та проіндексована, щоб її можна було шукати під час розмови. Ви можете вказати Quickchat AI URL вашої довідкової документації й дозволити зібрати сторінки, вставити статті вручну або завантажити файли. Під час відповіді Agent шукає в ній і відповідає з того, що знаходить, а не з того, що базова модель випадково пам’ятає про світ. Якщо ви починаєте з нуля, як створити базу знань для chatbot пояснює, що писати і в якому порядку.

Усе, що покривають ваші docs, отримує відповідь. Усе, що вони не покривають, стає тікетом.

Це головний важіль цієї збірки. Deflection це не трюк prompt і не можливість моделі: це ваше покриття. Якщо бот ескалує більше, ніж ви очікували, тікети показують, які сторінки ви ще не написали.

Ілюстрація, а не вимірювання. Суть у напрямку: написання docs є найвпливовішою роботою тут.

Чи може AI справді відповідати на запитання підтримки в Discord?

На запитання, які покривають ваші docs, так, і реальними кроками, а не переказом. Ось випадок deflection із тестового сервера, без редагування:

Відповідь у каналі, зі статті бази знань. Тікет не створено, тому що він не був потрібен.

Цікавіша частина це те, що відбувається, коли відповіді там немає. Бот прямо про це каже:

Чесна невдача. База знань Beacon навмисно не містить enterprise SSO, тому це шлях, який відкриває тікет.

Agent, який вигадує правдоподібну процедуру SSO, гірший за того, який відкриває тікет, тому цю поведінку варто навмисно тестувати, а не сподіватися на неї. Ми повернемося до цього в тестуванні.

Два способи підключити Discord і чому тікетам потрібен другий

Quickchat AI має два Discord-підключення, і різниця важлива до початку роботи.

Для публічної черги feedback, яка працює зі спільним ботом, див. workflow для feedback і documentation-gap. Private-ticket Actions нижче потребують облікових даних вашого власного Discord-бота.

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

Ви можете його назвати. Перед авторизацією є поле Bot name in the new server, попередньо заповнене ім’ям вашого Agent, і кожен підключений сервер має власне поле Bot name in this server, яке можна змінити пізніше. Це Discord nickname, тому він діє на рівні сервера й обмежений 32 символами, а очищення поля повертає бота до Quickchat AI. Спільними залишаються avatar і базовий @username, тому що один Discord application обслуговує кожен сервер, який його встановлює.

One-click не означає generic. Бот переносить ім’я вашого Agent на сервер, і ви можете змінити його для кожного сервера пізніше.

Advanced setup реєструє ваш власний Discord application. Ви створюєте бота в developer portal Discord і один раз вставляєте його token у Quickchat AI. Це займає близько десяти хвилин і дає вам власний avatar і @username, direct messages, кілька ботів на одному сервері та те, що потрібно цьому посібнику: Discord API Actions.

Причину варто сказати прямо, а не вважати примхою. Ticket Actions у цьому посібнику викликають Discord API від імені вашого бота, використовуючи credential, який Quickchat AI вставляє в запит під час надсилання. Token спільного one-click bot належить спільному боту, а не вам, тому він недоступний для надсилання вашими Actions. Якщо ви відкриєте Discord gallery без підключеного власного app, вона повідомить про це і вимкне картки, а не дозволить створити те, що не може виконатися.

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 перевіряє його під час введення. Посібник Create an AI Discord bot детально пояснює частину з portal, якщо ви ще цього не робили.

Надайте боту лише те, що потрібно боту підтримки. У ticket channel: View Channels, Send Messages, Read Message History, Create Private Threads, Send Messages in Threads і Manage Threads. Йому не потрібні дозволи Kick, Ban або Timeout, і в тестовому сервері він навмисно не має жодного з них. Бот підтримки не має причин модерувати, а дозвіл, якого він не має, ніколи не потрібно враховувати.

У Discord створіть дві речі, на які вказуватимуть Actions. Ця частина відбувається в Discord client, а не в Quickchat AI, і це єдине налаштування, яке ви робите там:

1. Канал, де відкриватимуться тікети. Підійде будь-який text channel. Використайте + поруч зі списком каналів або використайте наявний. У тестовому сервері це #support.
2. Роль, яку потрібно сповіщати, коли відкривається тікет. Server Settings, потім Roles, потім Create Role. У тестовому сервері це @support.

Три місця, і лише одне з них публічне.

Обидві речі повертаються в Step 3. Коли ви встановлюєте ticket template, Quickchat AI читає ваш сервер наживо з Discord і показує три списки, один із них Role picker зі знайденими ролями. Ви вибираєте роль підтримки там, а не вводите ID.

Role picker у Step 3. Він читає список із Discord, тому роль, яку ви створите зараз, з’явиться тут за мить.

Одна деталь створить проблему, якщо її пропустити: цей picker показує лише ролі, які Discord повідомляє як mentionable, і пропускає @everyone. Якщо ваша роль підтримки не позначена як mentionable, вона просто не з’явиться у списку, без пояснення чому. Фільтр навмисний, тому що вся робота шаблону полягає в тому, щоб сповістити цю роль. Увімкніть це під час створення ролі, і ви не зіткнетеся з проблемою:

Server Settings, Roles, виберіть роль підтримки й увімкніть це в Display. Без цього роль ніколи не потрапить до picker.

Як бот вирішує, відповідати чи відкривати тікет?

Більшість Discord ticket-ботів нічого не вирішують. Ticket Tool, TicketsBot та інші публікують закріплену панель із кнопкою Create Ticket або реєструють slash command. Учасник натискає її, відкривається тікет, і ваша команда його читає. Це нормальний дизайн і він повністю передбачуваний, але це означає, що десять людей, які цього тижня запитали, як скинути API key, створили десять тікетів.

Ті самі десять запитань. Різниця в тому, що врешті читає ваша команда.

Answer-first bot читає ваші docs перед рішенням. А коли він ескалує, відкриття одного тікета потребує рівно чотирьох фактів:

• у якому каналі відкривається thread
• з якого сервера надійшло запитання
• хто запитує, щоб його можна було додати до thread
• як називається тікет, і короткий підсумок проблеми

Цікаво те, що ці чотири факти надходять трьома цілком різними способами, і лише останній пише AI:

Ви ніколи не вводите Discord ID, а модель ніколи не бачить ваш канал або вашу роль.

Ті, які ви вибираєте один раз. Ваш ticket channel і ваша роль підтримки. Ви вибираєте їх зі списків під час встановлення шаблону, а Quickchat AI вбудовує їх в Action. Модель ніколи їх не бачить і не може змінити.

Ті, які надає Discord. З кожним пересланим повідомленням інтеграція Discord повідомляє Quickchat AI, з якого сервера воно надійшло і хто говорить, як {{metadata_discord_guild_id}} і {{metadata_discord_author_id}}. Token вашого бота надходить так само, як System Token, вставлений під час надсилання і замаскований усюди, де логуються виклики. Нічого з цього не вводить модель, і нічого з цього не може надати public chat або API message.

Ті, які пише Agent. Тема тікета і короткий підсумок проблеми. Це єдині judgment calls в усій збірці, тому подальше налаштування коротке.

Step 1: Створіть Agent і додайте йому базу знань

Створіть Agent, потім відкрийте Knowledge Base і додайте документацію. Вставте URL вашої help-docs і дайте Quickchat AI зібрати її, або пишіть статті напряму. Create an AI support agent from your documentation детально пояснює шлях зі scraping.

База знань Beacon: скидання API key, порожній dashboard, встановлення tracking snippet, plans and billing та export data.

Docs Beacon навмисно не покривають одну річ: налаштування enterprise SSO. Ця прогалина не є недоглядом у цьому tutorial, це його суть. Кожна база знань підтримки має запитання, на які не відповідає, і вся цінність цього бота полягає в тому, що він робить, коли натрапляє на таке запитання. SSO є таким запитанням у всьому посібнику.

Учасники звертаються до вашого власного бота, згадуючи його через @mention у каналі, який він бачить. Нічого реєструвати не потрібно. Команда /ask доступна у спільному one-click Quickchat AI bot.

Step 2: Скажіть Agent, коли відповідати і коли ескалувати

Інструкції Agent розміщуються в AI Main Prompt на Identity. Вставте це, адаптувавши до вашої компанії:

Ви Lumen, асистент підтримки 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 в один рядок про те, що запитав клієнт.
Потім скажіть клієнту, що його тікет відкрито і команда відповість у новому thread.
Ніколи не просіть у клієнта Discord ID, channel ID або thread ID. Вони заповнюються за вас.

AI Main Prompt на Identity. Це завжди доступне поле, а не окремий список guidelines.

Два рядки в цьому блоці є критичними. “Не вгадуйте і не вигадуйте кроки” перетворює прогалину знань на чесну відповідь, а не на правдоподібну. А називання трьох Actions по порядку змушує Agent викликати їх як послідовність, а не вибирати одну.

Порядок описано в prompt, але він забезпечується не лише там, про що йдеться в наступних двох розділах.

Step 3: Встановіть ticket Actions одним кліком

Відкрийте Actions & MCPs, натисніть Add Action і виберіть Discord Action.

Discord Action розміщена поряд з іншими one-click galleries.

Gallery відкривається з Discord templates, згрупованими за завданнями: Support & Tickets містить той, який використовує цей посібник, а Moderation містить ще сім.

Вісім карток. Open Support Ticket єдина, яка щось запитує.

Виберіть Open Support Ticket, і відкриється короткий крок configure. Це єдина форма в усій збірці:

Три списки, і діалог одразу каже, що саме він встановить.

Списки надходять наживо з Discord, відфільтровані до того, що справді може працювати. Канали лише text channels:

Виберіть канал, під яким мають відкриватися тікети. Threads створюються всередині нього.

А ролі лише mentionable roles, без @everyone:

Це фільтр, який приховує роль підтримки, яку ви ще не зробили mentionable.

Три вибори, і форма готова:

Уся конфігурація. Server, channel, role і єдина кнопка, яка має значення.

Натисніть Install and enable. Quickchat AI створює три Actions на бекенді, в одній transaction, уже активні.

Три картки, enabled, з іконкою Discord. Більше нічого заповнювати.

Дві речі варто знати про сім moderation templates, поки ви тут. Вони не потребують жодної конфігурації, тому що беруть server, member, role або channel із самого Discord request, тому натискання картки встановлює їх негайно. А встановлення template двічі дає другу редаговану копію, а не помилку, що є розумним способом створити варіант.

Що насправді створив цей один клік?

Це варто розуміти, хоча вам не довелося це вводити, тому що все, що ви можете захотіти змінити пізніше, розміщено тут.

Три звичайні HTTP Request Actions. Ніщо не позначає їх як special.

Вони з’єднані між собою через дві функції, які вже є в editor, і обидві варто знати за назвами.

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

Run only when обмежує Action станом conversation, і це перевіряється на боці Quickchat AI до надсилання будь-якого запиту. (Run only when у docs.)

Шлюз, який перетворює три незалежні Actions на надійну послідовність.

Читайте цю схему в обидва боки, тому що вона виконує дві задачі:

• Follow-ups вимагають, щоб thread ID існував, тому Agent не може сповістити вашу команду про thread, який ніколи не було створено.
• open_support_ticket вимагає, щоб його не існувало, тому Agent не може відкрити другий тікет у тій самій розмові, що б не казала розмова. Це гарантія, а не інструкція: якщо учасник додає деталі ще десять повідомлень, у нього все одно один тікет. У channel reply mode кожен обмін у каналі є власною conversation, тому наступне реальне запитання все ще може відкрити власний тікет.

Кожна Action також має Response filter, і його легко неправильно зрозуміти. Response filter це allowlist: він називає paths, які Agent дозволено бачити, а все інше у response відкидається до того, як модель це прочитає. (Response filter у docs.)

Discord повертає десяток полів про ваш сервер. Agent бачить два.

Thread ID, потрібний послідовності, захоплюється на боці Quickchat AI через Save to memory, тому Agent не має його переносити, і нічого іншого про ваш сервер не доходить до моделі. Звузьте allowlist ще більше, і вона бачитиме менше. Вона ніколи не бачить більше, ніж ви перелічили.

Чи може людина перебрати розмову від AI?

Так, і це та половина, яку більшість ticket-ботів пропускає. Тікет, який ніхто не читає, це просто thread.

Human Handoff це окрема вбудована Action. Увімкніть її та опишіть у Handoff Rules, коли розмова має перейти до людини, наприклад “коли клієнт просить людину або коли Agent не зміг відповісти з бази знань”. Quickchat AI потім позначає розмову у вашому Inbox підсумком, написаним AI, щоб той, хто її бере, читав абзац замість усього thread. Кожне налаштування handoff має власне пояснення в the Human Handoff tutorial.

Operator працює в Inbox. Учасник ніколи не залишає Discord.

Призначте розмову собі та відповідайте в Inbox composer. Ця відповідь доставляється прямо назад у Discord channel, де учасник уже говорить. Йому не потрібен обліковий запис у вас, email thread або portal login. AI мовчить із моменту, коли людина володіє розмовою, тому ви не конкуруєте з власним ботом.

Той самий канал, із різницею в три дні. Agent відмовився й ескалував; повідомлення нижче divider написала людина в Quickchat AI Inbox. Зауважте, що воно надходить під ім’ям вашого бота, тому що ваш бот є єдиною identity, від імені якої Discord дозволяє нам публікувати.

Та сама розмова з вашого боку. Відмова Agent, два Action calls за нею, відповідь operator нижче і details pane, яка вже знає, що channel це Discord, а topic це single sign-on.

Тим часом приватний ticket thread залишається там, де працює ваша команда: це робочий простір, з учасником усередині та сповіщеною роллю підтримки. Відповідь повертається туди, де поставили запитання.

Шість кроків. Три з них це записи в Discord, і всі три відбуваються лише тому, що відповіді бракувало.

Протестуйте обома шляхами

Запустіть обидва шляхи, перш ніж покладатися на це, і найретельніше тестуйте чесну невдачу.

Покрите запитання. Згадайте бота через @mention у каналі, який він бачить, і запитайте щось, що покриває ваша база знань. Ви маєте отримати реальні кроки в каналі, без thread деінде. Це випадок, який економить час вашої команди, і він становитиме більшість трафіку, коли docs стануть добрими.

Непокрите запитання. Запитайте те, чого немає у docs. Agent має сказати це і потім ескалувати. У той самий момент з’являється тікет:

Thread, який відкрив Agent. Він назвав його за проблемою, додав учасника, сповістив роль і сам написав підсумок.

І thread справді приватний, що доводить його власний список учасників:

Тікет це приватний thread. Розмови підтримки не відбуваються публічно.

Тестуйте всю розмову, а не одне повідомлення. Захист від дублікатів показує свою цінність лише на другому turn, коли учасник додає деталі, а наївний бот відкриває другий тікет.

Одна річ, яку run conditions не покривають. Вони зупиняють виклик у неправильному порядку, але не дедуплікують retry: якщо ви вручну повторно запустите notify Action, вона опублікує друге повідомлення. Це варто знати, перш ніж чіпати live ticket.

Щоб перевірити багато формулювань одразу, не вводячи їх усі в Discord, використовуйте Simulations у Testing: створіть dataset із customer messages, запустіть його проти вашого реального Agent і прочитайте scored results разом. Змішуйте покриті й непокриті запитання в одному dataset, тому що два шляхи ламаються по-різному.

Шість запитань, чотири покриті й два ні, оцінені за один запуск. Рядки 5 і 6 це чесні невдачі, і вони оцінюються так само високо, як відповіді.

Пишіть evaluation criteria для grader, який бачить лише transcript, тому що це все, що він отримує. Інакше вам коштуватимуть дві речі, яких він не бачить. Він не бачить Discord side effect, тому якщо ви цього не скажете, він читає “I’ve opened a ticket for you” як вигадування можливості Agent. І він не бачить вашу базу знань, тому знижує оцінку за правильну конкретну відповідь як fabricated просто тому, що не може перевірити число. Обидві речі варті одного речення в criteria, і обидві знижують оцінку вашій найкращій поведінці, якщо їх пропустити.

Як зупинити відкриття надто великої кількості тікетів?

Це єдине налаштування, потрібне більшості серверів, і переважно це не проблема prompt.

Обсяг тікетів це проблема бази знань. Кожна прогалина у ваших docs стає тікетом. Якщо бот ескалує більше, ніж ви очікували, прочитайте тікети: це список запитань, на які ваша документація не відповідає. Закриття цих прогалин прямо зменшує обсяг.

Insights підказує, що документувати далі. Quickchat AI групує розмови за topics, щоб ви бачили, які запитання виникають найчастіше, а не вгадували. Виправте три головні topics у базі знань і спостерігайте, як escalation rate падає.

Ніхто це не налаштовував. У Insights, Advanced, AI-Detected Topics назвали їх із самих розмов, а counts є backlog документації у пріоритетному порядку.

Цей список і є весь цикл налаштування. Pricing і API keys виникали найчастіше, тому ці статті пишуться першими, а графік наступного тижня показує, чи це спрацювало. Topics вище виявляються для вас; ви також можете визначити власні в Manage Topics, якщо хочете навмисно відстежувати конкретну продуктову область. Див. AI-Detected Topics, Conversation Topics і managing topics у docs.

Якщо він ескалує надто охоче, звузьте опис Action, щоб вона спрацьовувала лише після того, як Agent сказав учаснику, що не має інформації. Якщо він ескалує надто рідко і починає вгадувати, посильте рядок “не вгадуйте і не вигадуйте кроки” в main prompt.

Чи безпечно запускати це на публічному сервері?

Бот, з яким може говорити будь-хто в публічному каналі, потребує серйозної перевірки. Цей бот захищає конфігурація, яку можна прочитати в editor, а не формулювання prompt, тому захист працює незалежно від того, як сформульоване повідомлення.

Учасник може говорити з моделлю. Він не може обійти середній стовпець.

Кожна ticket Action вимагає реального Discord turn із вашого сервера. Дві з трьох run conditions у кожній Action перевіряють, що повідомлення справді надійшло через інтеграцію Discord і що воно прийшло з сервера, який ви вибрали під час встановлення. Ці значення створює інтеграція, а не повідомлення, і public chat або API message не можуть їх надати або успадкувати стару збережену копію. Спрямуйте public API вашого Agent на ці Actions, і вони відмовляться.

Action, яка додає когось до приватного thread, взагалі не має параметрів, які може редагувати модель. Її URL закінчується member ID, який інтеграція надала для поточного повідомлення. Agent не може передати інший, тому не може додати довільного учасника вашого сервера до чужого тікета.

Mentions зафіксовані під час встановлення. Notify Action надсилає явний mention list, що містить учасника, який запитав, і роль, яку ви вибрали, з вимкненим parsing. Mention, який Agent випадково напише в issue summary, не спрацює, і @everyone ніколи не може спрацювати. Це варто перевірити, а не просто довіряти, і це працює: role ping і user mention доходять, а literal @everyone у тому самому повідомленні нічого не робить.

Threads приватні й не допускають запрошення. Вони створюються як type: 12 з invitable: false, тому учасник, доданий до тікета, не може запросити когось іншого.

Бот не може модерувати. Він не має дозволів Kick, Ban або Timeout. Найгірший результат, якщо учасник переконає Agent зробити те, чого не слід, це ticket thread, який він міг би відкрити звичайним запитом.

Token ніколи не розкривається. Він зберігається як System Token, вставляється під час надсилання і маскується всюди, де записується call.

Одну річ варто вирішити навмисно: ticket threads приватні, але будь-хто з вашою роллю підтримки може їх читати, що саме й потрібно для підтримки, і це варто знати, якщо учасники можуть вставляти sensitive details. Для справді конфіденційного скеровуйте їх на email.

Скільки коштує Discord AI-бот підтримки?

План Free включає AI Actions, Human Handoff, базу знань, Topics і Insights, з 50 AI credits на місяць для особистого, некомерційного використання. Для бізнес-використання потрібен платний план; платні плани також надають більше AI credits. Якщо ви порівнюєте це із самостійним запуском, free AI Discord bots чесно порівнює self-hosted route, зокрема години, які він коштує.

Коли обидва шляхи проходять, запускайте Agent:

1. Спрямуйте учасників до бота. Напишіть у channel topic, що вони можуть згадувати його через @mention. Бот, про якого ніхто не знає, нічого не deflect.
2. Спостерігайте перший день. Кожна Action має call log із точним request і response, а Inbox містить кожну conversation, тому ви можете бачити, на що він відповів і що ескалував.
3. Читайте перші тікети як backlog документації. Це запитання, на які ваші docs ще не відповідають.

Той самий Agent працює і всюди в інших місцях. База знань, prompt і Human Handoff належать Agent, а не Discord, тому той самий бот підтримки відповідає у вашому website widget, у Slack, у WhatsApp та email, і кожна conversation потрапляє в той самий Inbox. Три ticket Actions є єдиною частиною цієї збірки, специфічною для Discord. Якщо ваша команда працює в Slack, а не Discord, надсилайте handoff notification туди замість сповіщення Discord role.

Що ще може робити ваш Discord AI Agent?

Та сама gallery містить категорію Moderation: timeout, kick, ban, unban, assign role, slowmode і announcements. Кожна з них встановлюється з run condition author_is_admin is true, тому запустити їх може лише server administrator, і цей flag надходить із Discord, а не з conversation. Це інший бот з іншим risk profile, і він має власний посібник: Build an AI Discord moderation bot.

Будь-який інший Discord endpoint працює за тим самим рецептом: HTTP Request Action із заголовком Authorization: Bot {{discord_bot_token}}, одним чи двома параметрами та plain-language description, який визначає, коли Agent її запускає. Build an AI Agent that takes actions це beginner version цієї ідеї, а Connect your AI Agent to any API покриває загальний випадок.

Не кожен Discord bot є ботом підтримки. Той самий Agent може натомість запускати персонажа: Discord AI roleplay bot використовує ту саму базу знань і memory для personas, а не tickets, а the full character build проходить persona prompt, canon і налаштування, які утримують його в образі.

Додаток: точні запити

Ви ніколи не вводите їх, але їх варто один раз прочитати, і саме це ви будували б вручну для будь-якої іншої платформи. Значення {{...}} заповнюються Quickchat AI під час надсилання.

1. Відкрити приватний 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 приватним. auto_archive_duration вказується в хвилинах, тому 1440 архівує тихий тікет через день. Save to memory захоплює $.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 і без параметрів. Обидва IDs надходять із memory та інтеграції.

3. Сповістити команду підтримки

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 це Bot, not Bearer, що є найпоширенішою помилкою під час ручного виклику Discord. А в allowed_mentions порожній parse разом із явними списками users і roles це те, що потрібно: він блокує @everyone, пропускаючи дві потрібні mentions. Непорожній parse поруч із явним списком того самого типу відхиляється одразу, з 400 MESSAGE_ALLOWED_MENTIONS_PARSE_EXCLUSIVE.

Пов’язані посібники

• Create an AI Discord bot, setup, який передбачає цей посібник
• Build an AI Discord moderation bot, та сама gallery, спрямована на moderation
• The best AI Discord bots, як порівнюються варіанти
• Free AI Discord bots, скільки насправді коштує self-hosting
• Discord AI roleplay bot, той самий Agent, який замість цього запускає персонажа
• Connect your AI Agent to HubSpot, та сама one-click gallery для CRM
• Make your AI Agent’s actions reliable, run conditions і memory детально
• Connect your AI Agent to any API, загальний рецепт
• How to build a chatbot knowledge base, половина, яка визначає обсяг тікетів
• Product tutorial: Human Handoff, пояснення кожного налаштування handoff

Поширені запитання

Як налаштувати ticket-бота в Discord?

Підключіть власний Discord app в External Apps, додайте Agent базу знань, потім відкрийте Actions and MCPs, натисніть Add Action, виберіть Discord Action і виберіть Open Support Ticket. Виберіть сервер, ticket channel і роль підтримки зі списків та натисніть Install and enable. Нічого не потрібно хостити, а в Discord не потрібно нічого налаштовувати, крім створення каналу та ролі.

Як створити Discord ticket-бота?

Створіть Quickchat AI Agent, підключіть власний Discord app, потім відкрийте Actions and MCPs, натисніть Add Action, виберіть Discord Action і виберіть Open Support Ticket. Ви вибираєте сервер, ticket channel і роль підтримки зі списків, натискаєте Install and enable, а Quickchat AI створює для вас три повні AI Actions. Спершу додайте Agent базу знань, тому що саме вона визначає, скільки тікетів він відкриватиме.

Чи може AI відповідати на запитання підтримки в Discord?

Так. Agent шукає у вашій базі знань і відповідає в каналі, коли знаходить відповідь. Deflection відстежує покриття: запитання, які покриває документація, отримують відповіді, а запитання, які вона не покриває, стають тікетами. Це співвідношення є найкориснішою річчю, яку варто розуміти під час роботи з цим ботом.

Чи потрібен код, щоб створити цього Discord ticket-бота?

Ні. Ви вибираєте шаблон із Discord gallery, вибираєте сервер, канал і роль зі списків, а Quickchat AI створює метод, URL, заголовки, body, параметри, налаштування відповіді та run conditions на бекенді. Ви ніколи не вводите Discord ID і ніколи не редагуєте JSON.

Скільки Actions встановлює шаблон?

Три. Одна відкриває приватний thread у вашому ticket channel і зберігає його ID у memory, друга додає учасника, який поставив запитання, а третя публікує підсумок зі згадкою вашої ролі підтримки. Вони одразу ввімкнені та з’єднані між собою.

Як бот знає, коли відкривати тікет?

Це визначають дві речі. Опис Action вказує Agent викликати її лише тоді, коли відповіді немає в базі знань, а run condition робить послідовність детермінованою: thread ще не має існувати, щоб його можна було відкрити, і має існувати, щоб могли виконатися наступні дії.

Чи може бот відкривати дублікати тікетів?

Не в межах тієї самої розмови. Open Support Ticket має run condition, яка вимагає, щоб у memory ще не було ticket thread ID, тому після створення одного тікета Agent не може відкрити другий для цієї розмови, що б не було написано в prompt.

Чи може людина перебрати розмову?

Так. Human Handoff позначає розмову у вашому Quickchat AI Inbox підсумком, написаним AI. Призначте її собі, напишіть відповідь в Inbox, і вона з’явиться в тому самому Discord-каналі, де вже перебуває учасник. Він не залишає Discord і не потребує облікового запису у вас.

Навіщо ticket-боту потрібен мій власний Discord app?

Ticket Actions викликають Discord API від імені вашого бота, тому їм потрібен token вашого бота. Спільний one-click Quickchat AI bot може відповідати на запитання та використовувати Google Sheets Actions. Його Discord token недоступний для ваших private-ticket Actions. В External Apps відкрийте Discord і виберіть Advanced setup, це займає близько десяти хвилин.

Які Discord permissions потрібні боту?

View Channels, Send Messages, Read Message History, Create Private Threads, Send Messages in Threads і Manage Threads у ticket channel. Боту підтримки не потрібні дозволи Kick, Ban або Timeout, а дозвіл, якого він не має, ніколи не потрібно враховувати.

Чому моєї ролі підтримки немає у списку?

Role picker показує лише ролі, які Discord повідомляє як mentionable, і виключає @everyone. Якщо ваша роль підтримки не позначена як mentionable у Server Settings, Roles, вона не з’явиться, тому що шаблон не зміг би її сповістити.

Чи безпечно запускати Discord ticket-бота на публічному сервері?

Захист задається конфігурацією, а не формулюванням prompt, тому працює незалежно від того, як сформульоване повідомлення. Кожна ticket Action вимагає, щоб turn справді надійшов із Discord і з вибраного вами сервера, Action, яка додає когось до приватного thread, взагалі не має параметрів, які може редагувати модель, mentions зафіксовані на учаснику, який запитав, і ролі, яку ви вибрали, а threads є приватними та не допускають запрошення. Run conditions перевіряються до того, як будь-який запит залишить Quickchat AI.

Скільки коштує Discord AI-бот підтримки?

План Free включає 50 AI credits на місяць для особистого, некомерційного використання. AI Actions, Human Handoff, база знань, Topics і Insights включені. Для бізнес-використання потрібен платний план; платні плани також надають більше AI credits.

У чому різниця між цим і Ticket Tool або TicketsBot?

Вони працюють за правилами. Учасник натискає кнопку Create Ticket на закріпленій панелі, і тікет відкривається щоразу, зокрема для запитання, на яке ваша документація вже відповідає. Цей бот спершу відповідає і ескалує лише те, що справді не може вирішити, тому ваша команда читає запитання, які справді потребують людини.

Чи можуть ChatGPT, Claude або Gemini запускати Discord ticket-бота?

Так, через Quickchat AI. Ваш Agent працює на найновіших моделях і викликає Discord API через ці AI Actions, тому відповідає з вашої бази знань і відкриває реальні приватні threads. Ви визначаєте, які Actions існують і що боту дозволено робити.

Чи може той самий Agent працювати в каналах, крім Discord?

Так. База знань, prompt і Human Handoff належать Agent, а не Discord, тому той самий бот підтримки відповідає у віджеті на вашому сайті, у Slack, WhatsApp та email. Три ticket Actions є єдиною частиною цієї збірки, специфічною для Discord.

Як учасники починають розмову з ботом?

Ticket-бот у цьому посібнику використовує ваш власний Discord app, тому учасники починають із @mention у каналі, який бот бачить. Agent відповідає в тому самому каналі та відкриває ticket thread лише тоді, коли не може відповісти. Команда /ask належить спільному one-click Quickchat AI bot.

Як зупинити відкриття надто великої кількості тікетів?

Спершу покращте покриття бази знань, тому що кожна прогалина стає тікетом. Читайте перші тікети як backlog документації і використовуйте Insights, щоб бачити, які теми виникають найчастіше, щоб знати, що писати далі. Лише після цього звужуйте опис Action.

Чи можу я редагувати Actions, які встановлює gallery?

Кожне поле. Це звичайні HTTP Request Actions, у яких немає нічого особливого: жодного блокування, badge або окремого policy layer. Змініть URL, body, опис або run conditions, або встановіть другу копію і редагуйте її.

Чи можу я запустити Discord ticket system без helpdesk?

Так. Тікет є приватним Discord thread, а черга є вашим Quickchat AI Inbox, тому Zendesk, Intercom або Jira не залучені й нічого не потрібно мігрувати. Якщо ви вже використовуєте helpdesk, можете залишити його: той самий Agent також може створювати там тікет іншою AI Action, і HubSpot gallery робить саме це.

Чи може бот відповідати з контенту нашого help center?

Саме на цьому він побудований. Вставте URL вашого help center, і Quickchat AI збере сторінки в базу знань, або завантажте файли та вставте статті напряму. Agent шукає в цих статтях на кожне запитання і відповідає в каналі, коли знаходить відповідь, тому ваша наявна документація стає ботом без переписування. Create an AI support agent from your documentation окремо пояснює цю половину.

Чи може бот привітати учасника, коли відкривається ticket channel?

Так, окремою функцією. Ticket-бот на кшталт Ticket Tool створює канал, а automated message Quickchat AI New channel публікує в ньому фіксоване привітання за кілька секунд, тому учасник одразу бачить, що є з ким говорити. Це не коштує credits, тому що модель не викликається. Greet members, threads and ticket channels налаштовує це.

Як вимірювати ticket deflection?

Deflection це частка запитань, на які відповіли без тікета, тому в цій збірці це розмови без ticket thread, поділені на всі розмови. Кожна Action веде call log, тому підрахунок викликів open_support_ticket прямо дає ескальовану частину, а Insights групує решту за темами. Відстежуйте це за темами, а не одним числом: падіння показника в одній темі є прогалиною документації, яку можна закрити. Chatbot analytics покриває ширший набір metrics.

Підсумок

З базою знань і одним кліком Quickchat AI Agent стає ботом підтримки першої лінії для вашого Discord server: він відповідає на запитання, які покривають ваші docs, визнає, коли вони не покривають, відкриває приватний ticket thread для решти, додає учасника, сповіщає роль підтримки підсумком, який написав сам, і передає розмову людині, яка відповідає з вашого Inbox, поки учасник ніколи не залишає Discord. Gallery створює три Actions, списки означають, що ви ніколи не вводите Discord ID, а run conditions означають, що послідовність зберігається навіть тоді, коли розмова не йде за планом. Залишається робота, яку можете зробити лише ви: база знань, з якої варто відповідати.