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

Що робить автоматизація

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

1. Категорія запиту — баг, питання з біллінгу, onboarding, how-to, feature request, cancellation, escalation.
2. Пріоритет — критичний інцидент, терміновий, звичайний, низький.
3. Маршрут — конкретний агент, команда або черга у helpdesk.

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

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

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

Робить:

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

Не робить:

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

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

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

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

Enterprise / команда 30+ агентів. Повноцінна маршрутизація з урахуванням навичок агентів, мов, часових зон і типів контрактів. Grow2.ai будує багаторівневу таксономію (25-40 категорій), інтеграцію з кількома системами (helpdesk + CRM + product analytics + billing). Для enterprise-клієнтів AI-агент розпізнає SLA-tier і маршрутизує тикети з урахуванням контрактних зобов'язань. Додається escalation-логіка: якщо тикет простоює X годин — автоматичний escalate. Окрема логіка для cancellation: такі листи йдуть у retention-команду з доданим контекстом по клієнту.

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

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

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

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

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

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

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

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

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

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

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

Класифікація побудована на prompt engineering з few-shot прикладами, не на fine-tuning. У такого підходу три переваги:

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

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

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

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

Безпека та compliance

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

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

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

1. Helpdesk з API і webhooks

Grow2.ai працює зі стандартними helpdesk-інструментами:

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

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

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

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

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

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

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

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

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

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

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

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