Сортування тікетів

AI-агент читає кожен новий тикет у службі підтримки і приймає три рішення за кілька секунд:

1. Категорія запиту — баг, питання з білінгу, онбординг, довідковий запит, запит на функцію, скасування, ескалація.
2. Пріоритет — критичний інцидент, терміновий, звичайний, низький.
3. Маршрут — конкретний агент, команда або черга у службі підтримки.

Автоматизація додає до тикету мітки, проставляє поля і пише внутрішню нотатку з коротким резюме запиту. Агент відкриває тикет і одразу бачить, про що він, до якого типу належить, який пріоритет і чому AI-агент прийняв таке рішення. Жодної сліпої довіри: класифікація прозора, агент може перекласифікувати одним кліком.

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

Що автоматизація робить і чого не робить

Робить:

• Класифікує тикети за категорією і пріоритетом на основі тексту звернення та контексту клієнта.
• Проставляє мітки, теги і власні поля у службі підтримки.
• Направляє тикет у потрібну чергу або конкретному агенту з урахуванням навантаження та навичок.
• Формує коротке резюме запиту для агента (2-3 речення).
• Розпізнає мову тикету і маршрутизує на відповідну мовну команду.

Не робить:

• Не відповідає клієнту самостійно — фінальну відповідь завжди пише людина.
• Не приймає рішень щодо повернень, знижок, цінових політик.
• Не замінює L2/L3-ескалацію — складні випадки залишаються за людьми.
• Не працює з системами підтримки без публічного API.
• Не закриває тикети автоматично і не позначає їх як спам без ручного підтвердження.

Типові варіанти налаштування

Solo / команда 1-5 агентів. Для невеликих команд автоматизація вирішує одне завдання: розвантажити вхідні. Grow2.ai налаштовує 5-7 базових категорій (баг, білінг, довідковий запит, запит на функцію, інше) і два рівні пріоритету. Маршрутизація проста: всі тикети йдуть у загальну чергу з мітками, агент сам розбирає за категоріями. Підключення — до однієї служби підтримки. Без кастомних полів і інтеграції з CRM. Запуск вкладається в 1-2 дні, навчання на історії з 500-1000 закритих тикетів.

SMB / команда 6-30 агентів. З'являються спеціалізовані черги: біллінг окремо, тех-підтримка окремо, онбординг окремо. Grow2.ai налаштовує 10-15 категорій з двома вимірами: категорія і під-категорія. Пріоритет — чотирирівневий, із SLA-тригерами. Маршрутизація враховує робочі години команд і поточне навантаження. Додається інтеграція з CRM для збагачення контексту: тикет від великого клієнта автоматично отримує високий пріоритет. AI-агент формує резюме і підтягує схожі вирішені тикети з бази знань.

Корпоративний сегмент / команда 30+ агентів. Повноцінна маршрутизація з урахуванням навичок агентів, мов, часових зон і типів контрактів. Grow2.ai будує багаторівневу таксономію (25-40 категорій), інтеграцію з кількома системами (служба підтримки + CRM + продуктова аналітика + білінг). Для корпоративних клієнтів AI-агент розпізнає SLA-рівень і маршрутизує тикети з урахуванням контрактних зобов'язань. Додається логіка ескалації: якщо тикет простоює X годин — автоматична ескалація. Окрема логіка для скасувань: такі листи йдуть у команду утримання з доданим контекстом по клієнту.

Як працює автоматизація

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

1. Вхідний шар

Служба підтримки (Zendesk, Intercom, Freshdesk, HelpScout, Front та аналоги) надсилає вебхук при створенні нового тикету. Якщо служба підтримки не підтримує вебхуки, Grow2.ai налаштовує опитування API раз на 30-60 секунд. Тикет потрапляє в обробник з усіма доступними полями: тема, тіло, канал (email, чат, форма), клієнт, вкладення, мова інтерфейсу.

2. Класифікатор

AI-агент на базі AI-моделі читає тикет разом з контекстом клієнта та повертає структуровану відповідь у форматі JSON: категорія, під-категорія, пріоритет, мова, імовірна команда-адресат, коротке резюме для агента, рівень впевненості. Промпт містить таксономію категорій компанії, приклади граничних випадків та правила пріоритизації. Для складніших класів додаються зразкові приклади з історії тикетів.

3. Шар збагачення (опціонально)

Перед класифікацією тикет збагачується контекстом із CRM: план клієнта, MRR, історія комунікацій, останні тикети, статус підписки. Збагачення дозволяє коригувати пріоритет: тикет від корпоративного клієнта з SLA не отримає низький пріоритет, навіть якщо текст звучить як тривіальний довідковий запит. Для SaaS-команд додається контекст із продуктової аналітики — видно, чи користувався клієнт фічею, з приводу якої він пише.

4. Вихідний шар

Результат класифікації повертається до служби підтримки через API: проставляються теги, призначається команда або конкретний агент, виставляється пріоритет, додається внутрішня нотатка з резюме від AI-агента. Якщо впевненість класифікатора нижче порога (наприклад, 70%) — тикет іде в загальну чергу з тегом needs_review та резюме, щоб людина прийняла рішення. Для всіх тикетів ведеться лог: який промпт, яка відповідь моделі, яка фінальна класифікація, чи виправляв агент. Цей лог — база для коригування таксономії.

Як відбувається навчання

Класифікація побудована на розробці промптів із зразковими прикладами, не на донавчанні. У такого підходу три переваги:

1. Швидкий запуск: не потрібно збирати розмічений датасет під кожного клієнта.
2. Легка корекція: якщо таксономія змінюється — правимо промпт, не тренуємо модель заново.
3. Прозорість: видно, за яким контекстом AI-агент прийняв рішення.

Grow2.ai будує таксономію на історії тикетів компанії: експортуються 500-2000 останніх закритих тикетів, виділяються стійкі категорії, описуються граничні випадки. Цей етап займає 1-2 дні спільної роботи з керівником підтримки. Далі раз на 2-4 тижні таксономія переглядається на основі виправлень, які роблять агенти.

Альтернативні підходи

Ручне сортування працює, поки команда маленька. На 10+ агентах диспетчер стає вузьким місцем: або компанія платить за окрему людину, яка весь день розкидає тикети, або сортують самі агенти — на шкоду швидкості відповіді. No-code правила в службі підтримки гарні для простих випадків ("якщо в темі слово 'invoice' — тег білінг"), але ламаються, коли клієнт пише вільним текстом: "питання з оплати", "мені надіслали рахунок не за те", "чому з мене списали двічі". AI-автоматизація закриває саме цю діру — розуміє зміст.

Безпека та відповідність вимогам

Тіло тикету обробляється зовнішньою LLM, що вимагає уваги до відповідності вимогам. Grow2.ai налаштовує попередню обробку: PII (email-адреси третіх осіб, номери карток, телефони, паспортні дані) маскується до відправки в модель. Для GDPR-чутливих сценаріїв доступний режим з AI-моделлю на Anthropic Enterprise plan — дані не використовуються для навчання моделі. Для регульованих індустрій (охорона здоров'я, фінанси) окремо оцінюється доцільність моделей власного розгортання замість зовнішнього API. Всі рішення класифікатора логуються разом з промптом та відповіддю моделі — для аудиту, діагностики та регулярного перегляду безпеки. Доступ до логів обмежений ролями у службі підтримки.

Що потрібно для запуску

Для старту потрібні три речі: служба підтримки з API, історія закритих тикетів і одна відповідальна людина на боці команди підтримки.

1. Служба підтримки з API і вебхуками

Grow2.ai працює зі стандартними інструментами служби підтримки:

• Zendesk — повний API і вебхуки.
• Intercom — повний API, події через вебхуки.
• Freshdesk — повний API, вебхуки через автоматизації.
• HelpScout — API з обмеженнями (для деяких подій використовується опитування).
• Front — API і вебхуки.

Для інших інструментів служби підтримки підтримка оцінюється окремо на етапі дискавері. Якщо служба підтримки власної розробки — потрібен публічний API для читання тикетів і запису міток.

2. Історія тикетів

Потрібен експорт 500-2000 закритих тикетів за останні 3-6 місяців. За цими даними Grow2.ai будує таксономію категорій і збирає зразкові приклади для промпту. Якщо історії менше 500 тикетів — класифікатор працює, але таксономія вийде грубішою, а перші тижні потребуватимуть більше коригувань.

3. Відповідальна людина

На боці компанії потрібен один керівник підтримки або старший агент, який:

• Погоджує таксономію категорій і під-категорій.
• Описує граничні випадки (що вважати "багом" vs "how-to", коли це "billing" vs "cancellation").
• Перевіряє перші 50-100 класифікацій AI-агента і дає зворотний зв'язок.

Ця людина витрачає 3-5 годин за перший тиждень запуску, потім роль переходить у регулярний моніторинг — 30-60 хвилин на тиждень.

Опціональні інтеграції

• CRM (HubSpot, Salesforce, Pipedrive) — збагачення тикету контекстом клієнта (план, MRR, статус).
• Продуктова аналітика (Amplitude, Mixpanel, PostHog) — зв'язок тикетів з подіями продукту.
• Система білінгу (Stripe, Chargebee) — для автоматичного пріоритету за MRR і статусом підписки.
• Slack — сповіщення про критичні тикети в канал команди.

Можливі підводні камені

1. Нечітка таксономія. Команди підтримки нерідко не можуть внутрішньо домовитися, що вважати "багом", а що — "how-to". AI-агент класифікує за таксономією, яку йому надали, — отже, домовленості потрібні до запуску, а не після.
2. Недостатньо історії. На 100-200 тикетах класифікатор працює, але few-shot приклади не покривають усіх випадків. На такому обсязі точність класифікації нижча, ніж на 1000+ тикетах, і перші 3-4 тижні потребуватимуть більше ручних коригувань.
3. Надто дрібна таксономія. Якщо категорій 40 з під-категоріями і під-під-категоріями, модель починає плутати близькі класи і знижує впевненість. Розумніше почати з 5-10 категорій і дробити в міру накопичення даних.
4. Відсутність петлі зворотного зв'язку. Якщо агенти виправляють класифікацію, але це не повертається в промпт і таксономію — одні й ті самі помилки повторюються тижнями. Потрібен регулярний (раз на 2-4 тижні) розбір неправильних класифікацій і коригування.
5. Недооцінка граничних випадків на запуску. Перші 2-3 тижні бувають казуси: тикет трьома мовами, прикріплений скриншот без тексту, перенаправлений лист від внутрішнього співробітника, автовідповідь від стороннього сервісу. Ці випадки потрібно відловлювати проактивним моніторингом, а не чекати скарг клієнтів.