Анализ support-тикетов как research-данных

Преврати поток support-тикетов за {{period}} в product research.

Источник: {{ticket_source}}

Принцип

Support-тикеты — самый дешёвый и самый недоиспользуемый research-канал. Клиенты сами тебе говорят что болит, бесплатно. Проблема в том, что их обычно тегируют по теме («billing», «integration»), а нужно — по root cause.

1. Импорт и подготовка

• Экспорт всех тикетов за {{period}} — CSV/JSON
• Поля: id, дата, плательный/бесплатный, тэги, тема, текст первого сообщения, время до закрытия, кол-во сообщений, оценка
• Отфильтруй FYI / спам / тестовые

2. Тегирование по root cause

Старый тег «billing» не отвечает на вопрос «что чинить». Перетегируй:

Метод: случайная выборка 200-300 тикетов → прочитай каждый → присвой 1 root cause. Только после этого автоматизируй (regex / LLM) для оставшихся.

Анти-паттерн: дать LLM сразу всю выборку. Без human calibration на 200 он не поймёт твою таксономию.

3. Паттерны: топ-N по effort

Считай не количество, а effort = (кол-во тикетов) × (средние сообщения на тикет) × (средняя длительность).

Это и есть бюджет проблем. Топ-3 root cause обычно занимают 40-60% effort.

4. Roadmap из бюджета

Для каждого топ-root-cause:

• Cost — часов support × ставка + estimated churn impact
• Fix size — XS/S/M/L (часы инженерии)
• ROI — cost / fix size
• Action — что именно делаем: bug fix / doc / UX / new feature / pricing change

## 2FA email delivery (18% effort)
Cost: 95h × $40 = $3,800 / квартал + ~12 churn cases
Fix: M (sender reputation + retry + clearer copy)
ROI: высокий
Action: Eng — switch transactional provider, P0

5. Метрики (для отслеживания)

• Recurrence rate — % тикетов того же root cause через 30 дней после фикса
• Ticket per active user — нормализует рост базы
• First-touch resolution — % закрытых за 1 ответ
• Topic shift — какие root cause растут / падают месяц к месяцу

6. Каденс

• Еженедельно: топ-3 новых паттерна (свежие, ещё не в roadmap)
• Ежемесячно: пересчёт effort budget
• Ежеквартально: review закрытых проблем — что вернулось

Что НЕ делать

❌ Считать тикеты «по тегу из тикет-системы» — теги ставит support, они отражают тему, не причину ❌ Топ-N по количеству — 200 мелких 1-message тикетов могут стоить меньше, чем 30 многосерийных ❌ Игнорировать «обходные» тикеты («я нашёл workaround») — это не «решено», это «компенсировано» ❌ Делать тэги только по продуктовым категориям — пропустишь «доверие», «миграция», «онбординг» ❌ Бросить тегирование после первого раза — таксономия дрейфует, ревизия раз в квартал ❌ Анализировать без support-команды — у них контекст «между строк»

На выходе

• Таксономия root cause (10-20 категорий)
• Перетегированная база за период
• Топ-10 root cause по effort с ROI и action
• 3-5 пунктов в roadmap с обоснованием цифрами
• Метрика recurrence для будущих фиксов