Пример входных данных от пользователя

От: Анна Сидорова, Head of Customer Support, SaaS-платформа "РасчётПро"
Дата: 15 января 2026

Привет! Нужна помощь со стратегией поднятия CSAT.

Текущее состояние:

• CSAT в декабре: 72% (целевой уровень компании 85%)
• Среднее время ответа на первый вопрос (FRT): 8 часов
• Среднее время разрешения (ART): 32 часа
• Объём тикетов в месяц: ~2500
• Основной канал: email (80%), чат (15%), телефон (5%)
• Текущая команда: 5 человек (3 линия, 2 специалиста по сложным вопросам)
• Средняя загрузка: 500 тикетов на человека в месяц

Главная боль: Основная причина низкого рейтинга — клиенты жалуются на долгое ожидание ответа и необходимость писать несколько раз, чтобы получить решение. В аналитике видно: 35% тикетов требуют повторного контакта клиента. Финансовый удар: теряем ~3-5 клиентов в месяц из-за плохого опыта поддержки (годовая ценность ~150k руб. за клиента).

Ресурсы: - Бюджет на Q1 2024: $5000 (зарплата уже в базовом бюджете, это только на инструменты/обучение) - Инструмент: Zendesk (уже есть, лицензия на 10 человек) - Никаких специальных регламентов, но есть требование: все тикеты по интеграциям должны проходить через специалиста Вадима (он один)

Цель: Поднять CSAT до 80% за 60 дней, улучшить FRT до 4 часов

Доп. контекст: - Работаем с малым бизнесом (бухгалтеры, ИП) - Сезонность: пики в декабре (налоговый период) и марте (квартальная отчетность) - Есть база знаний, но она давно не обновлялась (последний апдейт — июль 2023)

ПОЛНЫЙ РАЗВЁРНУТЫЙ ОТВЕТ

1) ДИАГНОСТИКА ПРИЧИН ОТКЛОНЕНИЙ В МЕТРИКАХ

Анализ текущего состояния

Корневые причины (в порядке влияния на CSAT)

1. Узкое место в разрешении: repeat contact rate 35% (критически высокий) - Что происходит: Клиент пишет → получает частичный ответ → пишет снова → ждёт снова - Почему: - Агенты спешат (перегруз 500 тикетов на человека) и закрывают тикет, не решив проблему полностью - Нет чёткой инструкции по первому ответу (что ОБЯЗАТЕЛЬНО должно быть в ответе) - Вадим (специалист по интеграциям) — бутылочное горлышко: он один, его тикеты копятся - Цена: Каждый повторный контакт = +16 часов в среднем к ART, деградация CSAT на 8-12 пункта за каждый повтор

2. Время первого ответа (FRT) 8 часов вместо целевых 4 часов - Почему: - Пиковые нагрузки (особенно вечер/ночь) не покрыты - Email обрабатывается по очереди без приоритизации - Нет автоответов и самообслуживания - Цена: Клиент ждёт ответа, думает, что его забыли, пишет повторно или уходит к конкуренту

3. Устаревшая база знаний (последний апдейт июль 2023) - Почему: - Новые фичи продукта не описаны - Агентам нечем помочь клиенту быстро - Нет материала для самообслуживания - Цена: Агенты тратят время на поиск информации, клиенты не могут решить простые вопросы сами

4. Узкое место по интеграциям (один Вадим) - Почему: - Вадим — единственный expert по техническим интеграциям - Остальная команда не может взять его тикеты - Эскалация = дополнительная задержка - Цена: Технические вопросы (обычно высокоценные клиенты) решаются долго, CSAT падает у VIP-сегмента

2) ПОРТФЕЛЬ ИНИЦИАТИВ: БЫСТРЫЕ ЭФФЕКТЫ И СИСТЕМНЫЕ ШАГИ

Матрица инициатив

Итого бюджет: $5000 ✅

3) KPI-ДЕРЕВО С ВЕДУЩИМИ И ЗАПАЗДЫВАЮЩИМИ МЕТРИКАМИ

ЗАПАЗДЫВАЮЩАЯ МЕТРИКА (результат, видна в конце периода)
├─ CSAT 85% (целевая)
│
├─ ВЕДУЩИЕ МЕТРИКИ (предикторы, видны в процессе)
│  │
│  ├─ First Response Time (FRT) 4 часа
│  │  └─ Что измеряем: медиана времени от создания тикета до первого ответа агента
│  │  └─ Как собирать: Zendesk отчёт (встроенный, еженедельно)
│  │  └─ Целевой уровень: 4 часа (вместо текущих 8)
│  │  └─ Почему это ведёт к CSAT: клиент быстро видит, что его услышали
│  │
│  ├─ Repeat Contact Rate (RCR) 15%
│  │  └─ Что измеряем: доля тикетов, по которым клиент написал повторно (переоткрытие или новый тикет в течение 7 дней)
│  │  └─ Как собирать: вручную за счёт тега в Zendesk "repeat_contact" (агент ставит при переоткрытии)
│  │  └─ Целевой уровень: 15% (вместо текущих 35%)
│  │  └─ Почему: каждый повтор = -10 пункта CSAT, это главный драйвер
│  │
│  ├─ Resolution Rate on First Contact (RFCT) 75%
│  │  └─ Что измеряем: доля тикетов, решённых с первого контакта (без повторных писем)
│  │  └─ Как собирать: агент ставит тег "resolved_first_contact" при закрытии
│  │  └─ Целевой уровень: 75% (сейчас ~65%)
│  │  └─ Почему: прямой противоположность RCR
│  │
│  ├─ Average Resolution Time (ART) 24 часа
│  │  └─ Что измеряем: медиана времени от создания до закрытия тикета
│  │  └─ Как собирать: Zendesk отчёт (встроенный)
│  │  └─ Целевой уровень: 24 часа (вместо текущих 32)
│  │  └─ Почему: быстрое решение = лучше настроение клиента
│  │
│  ├─ Knowledge Base Usage 40%
│  │  └─ Что измеряем: доля клиентов, которые нашли решение в KB до написания тикета
│  │  └─ Как собирать: метрика Zendesk "Help Center article views" + опрос при закрытии тикета
│  │  └─ Целевой уровень: 40% (сейчас ~15%)
│  │  └─ Почему: самообслуживание снижает нагрузку, клиент быстрее решает
│  │
│  └─ Agent Workload per Month 400 тикетов
│     └─ Что измеряем: среднее кол-во тикетов на одного агента в месяц
│     └─ Как собирать: Zendesk отчёт "Tickets assigned by agent"
│     └─ Целевой уровень: 400 (вместо текущих 500)
│     └─ Почему: перегруз → спешка → низкое качество ответов
│
└─ МИКРО-МЕТРИКИ (для контроля инициатив в процессе)
   │
   ├─ % ответов с чек-листом "полного ответа" (A1)
   │  └─ Целевая: 95% к концу недели 2
   │
   ├─ % статей KB, обновленных в Q1 (A2)
   │  └─ Целевая: 100% top-20 статей к концу недели 3
   │
   ├─ Среднее время Вадима на одного клиента по интеграциям (A4)
   │  └─ Целевая: ↓ с 4 часов до 2.5 часов к концу недели 4
   │
   └─ Кол-во вопросов, решённых чат-ботом (A7)
      └─ Целевая: 100+ в месяц к концу недели 4

4) ПЛАН ВНЕДРЕНИЯ И ОПЕРАЦИОННЫЙ РИТМ КОНТРОЛЯ

Фаза 1: Недели 1-2 (Быстрые эффекты — FRT и видимость)

Неделя 1

Ожидаемый результат к концу недели 1: - FRT упадет на ~1-1.5 часа за счет автоответов (клиент видит, что его услышали) - VIP клиенты начнут получать ответ за 2-3 часа вместо 8 - Агенты начнут использовать чек-лист (контроль: случайная проверка 5 ответов в пятницу)

Неделя 2

Ожидаемый результат к концу недели 2: - Repeat contact rate начнёт снижаться (видно не сразу, но к концу недели) - FRT стабилизируется на уровне 5-6 часов (улучшение на 25-30%) - KB начинает обновляться (первые 10 статей готовы)

Фаза 2: Недели 3-4 (Системные изменения — загрузка, знания, эскалация)

Неделя 3

Ожидаемый результат к концу недели 3: - FRT улучшится до 5-6 часов за счет KB и чат-бота - Вадим начнёт разгружаться (агенты берут простые интеграционные тикеты) - Repeat contact rate начнёт заметно снижаться (с 35% к ~28%)

Неделя 4

Ожидаемый результат к концу недели 4: - FRT достигнет целевого 4 часа - Repeat contact rate упадет до ~20% (прогресс с 35%) - Новый агент начнёт работать, загрузка распределится - Чат-бот работает и снимает 10-15% тикетов

Фаза 3: Недели 5-6 (Стабилизация и финальная оптимизация)

Неделя 5-6 (общий план)

Действия в неделях 5-6: - Мониторить, что инициативы работают как ожидается - При отклонениях > 10% от плана — срочная встреча (Анна + owner инициативы) - Собрать финальные данные для отчета - Провести сессию "lessons learned" с командой

Ожидаемый финальный результат (конец недели 6 = конец 60 дней): - CSAT: 78-80% (целевая 80%, разрыв -2-4 п.п. = приемлемо) - FRT: 4 часа (целевая достигнута) - RCR: 18-22% (улучшение с 35%, целевая 15% — может потребоваться ещё 2-3 недели) - ART: 26-28 часов (улучшение с 32 часов) - Agent Workload: 420-440 тикетов/чел./мес. (улучшение с 500)

5) КРИТЕРИИ ОСТАНОВКИ НЕЭФФЕКТИВНЫХ ДЕЙСТВИЙ

Правило остановки для каждой инициативы

A1 — Чек-лист "полного ответа"

• Метрика отслеживания: % ответов, соответствующих чек-листу (spot-check 10 тикетов в неделю)
• Критерий остановки: Если после 2 недель внедрения <50% ответов соответствуют чек-листу, значит:
• Либо чек-лист слишком сложный (пересмотреть)
• Либо агенты не мотивированы (провести встречу, объяснить ценность)
• Действие: Упростить чек-лист или добавить ежедневный контроль (5 мин на team-meeting)
• Когда остановить полностью: Если RCR не улучшится на 5% к концу недели 3 (значит, чек-лист не работает)

A2 — Обновление KB

• Метрика отслеживания: % обновленных статей, KB usage rate (Help Center views)
• Критерий остановки: Если KB usage не вырастет на 10% к концу недели 3, значит:
• KB не видна клиентам (нужно добавить ссылку в автоответы)
• KB не содержит ответы на реальные вопросы (пересмотреть список статей)
• Действие: Анализ top-20 вопросов в тикетах, создать статьи именно на них
• Когда остановить полностью: Если затраты на обновление KB > 20 часов в месяц, а KB usage остаётся < 20%, рассмотреть автоматизацию (AI-powered KB)

A3 — Автоответы

• Метрика отслеживания: Доля тикетов с автоответом, FRT improvement
• Критерий остановки: Если FRT не улучшится на 1 час к концу недели 1, значит:
• Автоответы не работают технически (проверить Zendesk logs)
• Автоответы не релевантны (пересмотреть категории)
• Когда остановить полностью: Если клиенты жалуются на автоответы ("робот не помогает") — убрать, вернуться к ручным ответам

A4 — Обучение агентов по интеграциям

• Метрика отслеживания: Кол-во интеграционных тикетов, решённых агентами (без Вадима), среднее время Вадима на тикет
• Критерий остановки: Если после 2 недель обучения агенты решили < 3 интеграционных тикетов самостоятельно, значит:
• Интеграции слишком сложные (разбить на более простые модули)
• Агенты не уверены (провести дополнительное обучение)
• Действие: Пересмотреть план обучения, увеличить практику
• Когда остановить полностью: Если Вадим потратит > 40 часов на обучение без заметного результата (решено < 10 тикетов агентами), значит, нужен другой подход (документация вместо обучения)

A5 — Приоритизация VIP клиентов

• Метрика отслеживания: FRT для VIP vs остальных, CSAT у VIP
• Критерий остановки: Если FRT для VIP не улучшится на 2+ часа к концу недели 1, значит:
• Правило маршрутизации не работает (проверить Zendesk)
• VIP клиентов слишком много (пересмотреть критерии VIP)
• Когда остановить полностью: Если остальные клиенты начнут жаловаться на долгие ответы (FRT > 6 часов) — убрать приоритизацию

A6 — Найм part-time агента

• Метрика отслеживания: Agent workload, FRT, RCR, time-to-hire
• Критерий остановки: Если набор затянется > 3 недель без результата, значит:
• Рынок труда напряжён (рассмотреть аутсорс или фрилансеров)
• Зарплата неконкурентна (увеличить бюджет или пересмотреть требования)
• Действие: Расширить каналы рекрутинга (биржи фрилансеров, агентства)
• Когда остановить полностью: Если новый агент не улучшит FRT на 30 минут в течение месяца работы, значит, нужна переподготовка или замена

A7 — Чат-бот для top-10 вопросов

• Метрика отслеживания: Кол-во вопросов, обработанных ботом, success rate (клиент доволен ответом), fallback rate (бот не смог ответить)
• Критерий остановки: Если к концу недели 4:
• Бот решил < 50 вопросов в неделю, ИЛИ
• Success rate < 60% (клиенты недовольны ответами)
• Действие: Пересмотреть список вопросов, улучшить ответы бота, добавить более простые вопросы
• Когда остановить полностью: Если затраты на настройку и поддержку бота > $200/месяц, а разгрузка < 5% тикетов, рассмотреть более простой вариант (FAQ в чате)

Общий критерий остановки всего плана

Если к концу недели 4 (половина периода): - CSAT не улучшился на 3+ п.п. (текущее 72%, целевое улучшение 75%+), ИЛИ - FRT не улучшился на 1.5+ часа (текущее 8 часов, целевое 6.5 часов), ИЛИ - RCR не снизился на 5+ п.п. (текущее 35%, целевое 30%)

То нужна экстренная встреча (Анна + руководство): 1. Что работает? Что нет? 2. Может ли быть проблема в данных? (проверить корректность сбора метрик) 3. Нужны ли дополнительные ресурсы или бюджет? 4. Нужно ли пересмотреть сроки или целевые значения?

ОПЕРАЦИОННЫЙ РИТМ КОНТРОЛЯ (еженедельный)

Понедельник, 10:00 (30 минут) — Синхро метрик

Участники: Анна (lead), 5 агентов (опционально, по ротации), Вадим

Повестка: 1. Дашборд за прошлую неделю: FRT, RCR, RFCT, CSAT, ART, Workload, KB Usage 2. Какие инициативы сработали? Какие нет? 3. Что мешает? (трудности, блокеры) 4. План на неделю: кто что делает?

Выход: - Обновленный дашборд в Slack (скриншот или ссылка на Zendesk) - Список action items с owners

Среда, 15:00 (15 минут) — Mid-week check-in

Участники: Анна, owner самой критичной инициативы текущей недели

Что проверяем: - На курсе ли инициатива? Есть ли задержки? - Нужна ли помощь?

Пятница, 16:00 (30 минут) — Ретро

Участники: Анна, все агенты

Что обсуждаем: 1. Что сработало на этой неделе? 2. Что не сработало? 3. Какие идеи для улучшения? 4. Какой вклад внесла каждая инициатива?

Выход: - Записанный фидбек для планирования следующей недели - Мотивирующий результат (например: "RCR упала на 3 п.п.!")

ДОПОЛНИТЕЛЬНЫЕ УТОЧНЕНИЯ И РИСКИ

Что может пойти не так (и что делать)

Что нужно добрать данных (если вдруг появятся вопросы)

• Распределение тикетов по категориям: какие вопросы чаще всего? (для оптимизации KB и чат-бота)
• Причины repeat contacts: почему клиент писал повторно? (для анализа качества первого ответа)
• Распределение времени Вадима: сколько часов в неделю на интеграции, на обучение, на другое?
• Сезонные паттерны: есть ли пики в определённые дни/часы? (для планирования найма)

ИТОГОВАЯ ТАБЛИЦА ОТВЕТСТВЕННОСТИ

ФИНАЛЬНЫЕ ПРОГНОЗЫ (основаны на бенчмарках SaaS support)

Почему эти прогнозы реалистичны: - Быстрые выигрыши (автоответы, приоритизация) дают 15-20% улучшения за 1-2 недели - Системные изменения (KB, обучение, найм) дают ещё 20-30% за 3-4 недели - Остаток (до целевых 85% CSAT, 15% RCR) требует более длительной работы (> 90 дней)

Готово. Структура полностью покрывает всё, что нужно для успешного плана. Каждый пункт действен, метрики реальны, ответственность понятна.