ШІ-бот ShipStation закриває 97,5% ІТ-запитів у Slack

Коли бот мовчить: соціальна логіка проти технічної

У команди ShipStation Global склалося правило: бот у спільному каналі спершу «ламається» соціально, а вже потім технічно. Тому найважливіша частина логіки Deckhand — не пошук відповіді, а рішення не відповідати. Перший крок агента для кожного повідомлення — визначити, чи це оголошення, соціальна фраза чи розмова між людьми. Якщо так, агент виводить SKIP, і Slack-сервіс просто не публікує відповідь.

У тредах бот відповідає лише автору питання. Якщо останню репліку написала інша людина-помічник, Deckhand мовчить — вважається, що проблему вже підхопив колега. А якщо повідомлення починається зі згадки конкретної людини через «@», бот розуміє, що звернення не до нього.

Як із хаотичної переписки Slack видобули робочу базу знань

Найцінніше джерело знань для Deckhand — не Confluence чи інтранет, а архів вирішених тредів у Slack: роками співробітники описували проблеми, а ІТ покроково допомагало. Але такий архів «шумний»: туди потрапляють жарти, автоматичні сповіщення й треди, які так і не отримали рішення. Якщо індексувати неперевірений фікс, база знань видасть неправильну відповідь із такою ж впевненістю, як і правильну.

Видобування даних побудоване як тристадійний конвеєр. Спочатку скрипт через Slack API експортує повну історію каналу з усіма відповідями, позначками тредів і часовими метками. Далі DSPy Recursive Language Model на базі Claude у Bedrock обробляє цей експорт не як один запит, а як навігований простір пам'яті в ізольованому Python-середовищі: модель класифікує кожен тред як вирішений, невирішений або переданий далі й відсіює оголошення й неінформативні повідомлення. Критерій жорсткий — тред рахується вирішеним лише тоді, коли повне робоче рішення видно безпосередньо в треді.

Для кожного вирішеного треду модель рекурсивно викликає під-LLM, щоб витягти структуровані поля — опис проблеми, оригінальне питання, рішення, чи фікс самообслуговуваний чи потребує тікета, покрокові інструкції, застосунок, повідомлення про помилку, теги. Кожне поле перевіряється за Pydantic-моделлю; якщо відповідь не проходить перевірку, цикл-інтерпретатор перехоплює помилку й повторює запит. Результат зберігається як markdown-документ, структурований за темами, і завантажується в S3 для індексації базою знань.

Захист від помилок і зловживань

Правила в промпті підсилюють поведінку, але не замінюють контроль доступу — його забезпечують код та інфраструктура. Створення тікета вимагає явного підтвердження: коли Deckhand пропонує завести тікет, у Slack з'являється кнопка «Create Ticket», і лише натискання запускає підтвердження через агента. Оновлення тікетів приймають тільки валідні ключі за шаблоном проєкту служби підтримки й відхиляють порожні коментарі.

Класифікація запиту перевіряється окремим викликом Amazon Bedrock Converse API, який повертає структуровані поля тікета, валідовані Pydantic ще до того, як вони потрапляють у Jira. Інструмент аналізу зображень обмежений завантаженням лише з хостингу файлів Slack, авторизується через токен бота й приймає не більше п'яти зображень до 5 МБ кожне. Усі токени Slack, секрет підпису й облікові дані Jira зберігаються в AWS Secrets Manager, а кожен сервіс працює під власною обмеженою IAM-роллю. У промпт додатково закладено заборони: ніколи не запитувати паролі чи MFA-коди, ніколи не записувати облікові дані в коментарі тікетів, ніколи не розкривати метадані профілю, які використовуються для полів тікета.

Результати за три місяці та умова, без якої підхід не працює

Deckhand запустили у квітні 2026 року: спершу близько 30 повідомлень на день, до початку літа — вже до 100. За перші три місяці бот обробив 1935 повідомлень, розпочав 1221 діалог з агентом і відкрив 409 тікетів у Jira, відповівши на 97,5% звернень. Третина питань надходила поза робочими годинами, і на них бот відповів у 94% випадків — люди отримували відповідь уночі, а не чекали до ранку.

Оцінка відповідей зростала разом із доопрацюванням: позитивні відгуки піднялися з 82% у квітні до 96% у червні, після того як команда переглянула системний промпт і базу знань на основі скарг користувачів. Головний економічний ефект — не самі відповіді, а відхилення тікетів: із 1221 діалогу лише 409 перетворилися на тікет, решту 812 закрили просто в чаті. Якщо завести й закрити тікет займає близько 30 хвилин, ці 812 діалогів зекономили приблизно 406 годин за три місяці, або близько 1600 годин на рік.

У джерелі окремо підкреслено умову успіху: подібне рішення варто починати з добре підтримуваного джерела знань і чітко визначеної дії — без цього агент не має на чому вчитися відрізняти вирішені випадки від шуму.