AI-маршрутизація тікетів + контроль SLA

Сценарій

Сценарій поштової скриньки підтримки інтернет-магазину: магазин спешелті-кави з роздрібним напрямком і оптовою лінійкою для кав’ярень і ресторанів, близько 350 листів на місяць надходять в одну спільну Gmail-скриньку — статус доставки, оплати, скарги, консультації щодо товару, оптові запити, спам. До автоматизації менеджери сортували скриньку вручну, без порядку пріоритетності й без відстеження часу відповіді.

Біль	Наслідок
Ручний тріаж спільної скриньки	Години до першої відповіді; менеджер перетворюється на «людський маршрутизатор»
VIP/B2B-звернення губляться серед рутинних питань і спаму	Ризик втратити найцінніший сегмент
Немає відстеження SLA чи дедлайнів	Тікети днями лежать непоміченими
Немає видимості реальних потреб клієнтів	Рішення власника ухвалюються наосліп

Що я побудував

Два workflow в n8n зі спільним журналом тікетів у Google Sheets.

SMK Ticket Routing (тригер Gmail, перевірка щохвилини) відсіює автовідповіді й noreply-листи, а потім проганяє кожен тікет через класифікатор із ланцюгом міркувань — GPT-4o-mini через OpenRouter, режим JSON, температура 0,2. Промпт складається з п’яти блоків: роль, бізнес-контекст, інструкція за трьома осями (зміст / вплив / терміновість), п’ятикроковий ланцюг міркувань, стиснутий у поле reasoning на 2–3 речення, і суворий формат відповіді. Шість категорій, кожна з призначеним відповідальним — доставка, оплата, консультація щодо товару, скарга, опт, спам. Пріоритети мають фіксовані SLA: P1 = 30 хв (подвійне списання коштів, юридичні погрози, зіпсована B2B-партія), P2 = 120 хв, P3 = 8 год, P4 = 24 год — з VIP-правилом, за яким будь-який B2B-тікет отримує щонайменше P2. Крок Validate & Enrich парсить JSON моделі з fallback-логікою (некоректний JSON знижується до P2 плюс ручна перевірка) і обчислює дедлайн SLA за канонічною таблицею відповідності «пріоритет → хвилини» в коді, а не за числом, яке запропонувала LLM. Кожен тікет логується в Sheets по 15 полях і публікується в Telegram.

SMK SLA Watcher (за розкладом, кожні 15 хвилин) читає відкриті тікети і для всього, що прострочило дедлайн, ескалує залежно від того, наскільки прострочено: L1 відразу — нагадування відповідальному за тікет, L2 через 30 хвилин прострочення — Support Lead, L3 через 2 години — власнику/CEO. Кожен рівень спрацьовує рівно один раз: escalation_level записується назад у таблицю, тож наступний запуск ніколи не сповіщає той самий рівень повторно.

Архітектура

Діаграма вище відповідає робочим workflow: Gmail живить класифікатор, який записує повністю оформлений тікет — категорію, відповідального, пріоритет, дедлайн SLA — у спільну таблицю і сповіщає в Telegram, поки окремий вотчер із 15-хвилинним інтервалом читає ту саму таблицю й ескалує все прострочене через три рівні.

Уроки, які сформували систему

• Показник впевненості моделі виявився марним для маршрутизації. Усі 13 тестових тікетів повернулися зі значенням confidence: 0.95 — поле не несло жодного розрізнювального сигналу, тож архітектура ніколи не маршрутизує на його основі.
• Хвилини SLA мають братися з коду, а не від моделі. Канонічна таблиця «пріоритет → хвилини» живе в кроці Validate & Enrich; власне число від LLM відкидається. LLM — не джерело істини для фіксованого бізнес-правила.
• Редагування живого polling-workflow скидає його чекпоінт. Під час тестування правка workflow скинула чекпоінт тригера Gmail, і вже оброблений лист повторно потрапив у систему як дубльований тікет. Продакшн-рішення: Gmail-лейбл Ticketed плюс фільтр -label:Ticketed у тригері, тож ідемпотентність живе в самому Gmail, а не в стані workflow.
• Власний підпис n8n просочився в класифікатор. Перший тестовий лист приніс підпис вихідного повідомлення n8n у вхідні дані моделі як частину «тіла листа» — виправлено вимкненням appendAttribution на ноді сповіщення.

Результати

Метрики виміряні в тестових прогонах — це демо-білд, а не відгук клієнта.

Метрика	До	Після
Час маршрутизації тікета	години (ручний тріаж)	~7 секунд
Точність класифікації (тестова вибірка)	—	12/12 правильно за категорією і пріоритетом
Тікети під контролем SLA	0%	100% (у кожного тікета є дедлайн)
Ескалації під час тестування	—	4 сповіщення на 3 рівнях (L1×2, L2, L3), кожне рівно один раз
Спам у командній скриньці	сортувався вручну	закривається автоматично (4 з 13 тестових листів)
Вартість AI-класифікації	—	~$0,11/місяць при 350 тікетах