Заявки распределяет человек вручную
Руководитель поддержки утром раскладывает тикеты по исполнителям в интерфейсе или таблице. При 200–300 обращениях в день часть из них остаётся без владельца до конца смены.
Маршрутизация и SLA
Маршрутизация, при которой ни одна заявка не теряется между каналами
Автоматически определяем тему и срочность обращения, распределяем его по компетенциям и текущей загрузке агентов и следим за сроком реакции. Почта, чат, телефония и мессенджеры приходят в один инбокс с единой нумерацией.
Или сразу: +7 (962) 368-39-51 Telegram
FRT
время первого ответа под контролем таймеров
3 модели
правила, компетенции и загрузка агентов
1 инбокс
почта, чат, телефония и мессенджеры
дедупликация
повторы склеиваются в одну заявку
Где ломается распределение обращений
Очередь растёт не от объёма заявок, а от того, что часть из них ждёт назначения, дублируется и попадает не к тому специалисту.
Обращения разбросаны по каналам
Клиент пишет на почту, дублирует вопрос в чат на сайте, затем звонит. Тикеты живут в трёх системах, и никто не видит полную картину по одному клиенту и по одному вопросу.
Дубли раздувают очередь
Одно и то же обращение приходит от клиента, от его бухгалтерии и через форму на сайте. Агенты готовят три ответа вместо одного, а отчётность показывает ложный рост нагрузки.
Срок реакции истекает незаметно
Приоритет выставляется по ощущению: срочный запрос крупного клиента стоит в очереди рядом с вопросом о цвете кнопки, и нарушение SLA обнаруживается уже по жалобе.
Заявка уходит не по компетенции
Вопрос по обмену с 1С попадает на агента первой линии, который переспрашивает детали и всё равно эскалирует. Время решения растёт, клиент повторяет данные дважды.
Метрики собираются вручную и с задержкой
FRT, ART, backlog и доля нарушений SLA считаются из выгрузок раз в неделю. К моменту отчёта восстановить причину провала по конкретной линии уже невозможно.
Что настраиваем в распределении заявок
Начинаем с таксономии и сроков, затем автоматизируем разбор и маршрут, а метрики считаем из тех же данных, по которым работает распределение.
Классификация и приоритизация
Тема и срочность определяются по содержанию обращения, а не по категории, которую выбрал клиент в форме.
- Определение темы и намерения по тексту письма, сообщения и расшифровке звонка
- Расчёт срочности: тип клиента, договорные сроки, признаки блокирующей проблемы
- Автоматические теги: продукт, модуль, регион, язык обращения, канал
- Обучение модели на исправлениях агентов вместо ручной правки правил
Маршрутизация по компетенциям и загрузке
Заявка уходит к специалисту, который действительно решает такие вопросы, и не зависает, если он занят.
- Матрица компетенций: кто из агентов ведёт какие темы и на каком уровне
- Учёт текущей загрузки, смены, часового пояса и доступности агента
- Правила эскалации при отсутствии ответа и при повторном обращении клиента
- Резервный маршрут: без владельца заявка не остаётся ни в одной ситуации
Омниканальный инбокс и склейка дублей
Все каналы приведены к одной карточке клиента, повторы объединяются автоматически.
- Почта, чат на сайте, телефония, Telegram и WhatsApp в одном рабочем месте
- Дедупликация по клиенту, теме и временному окну вместо ручного поиска повторов
- Склейка переписки и записи звонка в одну карточку с полной историей
- Единая нумерация заявок независимо от того, откуда пришло обращение
SLA, отчётность и интеграции
Сроки считаются по календарю поддержки, а данные попадают в вашу helpdesk-систему без ручного переноса.
- Политики SLA по приоритетам с таймерами и предупреждениями до нарушения
- Метрики FRT, ART, время решения, backlog и доля нарушений по каналам
- Двусторонняя синхронизация с Bitrix24, Jira Service Management и Usedesk
- Оповещения руководителя при риске просрочки и при росте очереди
Как мы выстраиваем маршрутизацию
Работу делим на четыре этапа: от разбора фактического потока обращений до настройки правил по реальным метрикам.
-
01 1–2 недели
Аудит потока обращений
Смотрим, откуда приходят заявки, как распределяются сейчас, где теряются и какие сроки реально соблюдаются. Считаем объём по каналам, темам и часам суток.
-
02 1–2 недели
Таксономия, приоритеты и SLA
Согласуем список тем, уровни приоритета, сроки реакции и решения по каждому. Фиксируем матрицу компетенций, дежурства и правила эскалации.
-
03 3–6 недель
Настройка и интеграции
Настраиваем классификацию, маршрутизацию, единый инбокс и склейку дублей. Подключаем helpdesk и CRM через API и вебхуки, переносим открытые заявки.
-
04 3–4 недели
Пилот, метрики и донастройка
Запускаем на одном канале или продуктовой линии, сверяем FRT и backlog с прогнозом, правим правила распределения по фактическим данным пилота.
Почему одних правил маршрутизации недостаточно
Правила вида «если тема доставка, назначить на группу логистики» работают ровно до первого нестандартного обращения. Реальные письма содержат несколько вопросов сразу, тему в свободной форме и вложения, а часть заявок приходит без явной категории. Через полгода такой набор правил становится неподдерживаемым: никто не помнит, зачем добавлено условие, и никто не решается его удалить.
Рабочая схема сочетает три слоя: жёсткие правила для однозначных случаев, модель классификации для свободного текста и загрузку агентов как финальный фильтр при назначении. Ключевое отличие от чистых правил — обратная связь: когда агент переназначает заявку или меняет тег, это исправление становится обучающим примером, и качество разбора растёт без переписывания условий вручную.
Как считать SLA, чтобы он отражал реальность
Первый вопрос при настройке SLA — по какому календарю считать время. Если срок реакции 4 часа применить к круглосуточному календарю, то заявка, пришедшая в пятницу вечером, будет формально просрочена в субботу ночью. Поэтому таймеры привязываются к календарю поддержки конкретной линии: рабочие часы, выходные, праздники и график дежурств.
Второй вопрос — какие метрики показывать. First Response Time отвечает на вопрос, как быстро клиент получил первый содержательный ответ; Average Resolution Time показывает, сколько живёт заявка целиком; backlog — сколько обращений ждёт решения прямо сейчас. Смотреть их нужно в разрезе канала, темы и приоритета: средний FRT по всей поддержке почти всегда скрывает линию, где сроки нарушаются системно.
Дедупликация: как объединять обращения и не терять клиента
Склейка дублей экономит время агентов, но у неё есть риск: если объединить два разных вопроса одного клиента, второй останется без ответа, и никто этого не заметит. Поэтому автоматическая склейка должна работать по консервативным признакам: один и тот же контакт, совпадение темы, окно в несколько часов и отсутствие ответа агента по первому обращению.
Дальше важна прозрачность. В объединённой карточке видно, какие обращения в неё вошли, из каких каналов и в какое время — при разборе всегда можно понять, что именно произошло. Если признаки сработали спорно, агент разделяет заявки обратно одним действием, и это решение тоже становится примером для настройки правил.
Частые вопросы
Тогда проект начинается с выбора системы под ваш процесс: для поддержки внешних клиентов обычно подходят Usedesk или Bitrix24, для внутренней ИТ-поддержки — Jira Service Management. Мы помогаем сравнить варианты по стоимости лицензий, гибкости правил и открытости API, а затем настраиваем маршрутизацию уже внутри выбранной системы, чтобы не создавать ещё один остров данных.
На типовом потоке поддержки модель определяет тему с точностью 85–92% на десяти-пятнадцати категориях, и этот показатель мы проверяем на вашей истории обращений до внедрения. Важнее точности — поведение при неуверенности: если модель не набирает порог по двум-трём темам, заявка уходит в общую очередь с пометкой, а не назначается наугад специалисту.
Да, и для большинства линий это правильнее. Таймер привязывается к календарю поддержки: рабочие часы, выходные, праздничные дни и график дежурств. Для клиентов на круглосуточном обслуживании можно задать отдельную политику с непрерывным отсчётом. Разные политики могут действовать одновременно для разных приоритетов и разных договоров.
Эффект складывается из трёх частей: сокращение времени первого ответа, снятие ручной сортировки с руководителя смены и уменьшение числа повторных обращений за счёт склейки дублей. В проектах со 200 и более обращениями в день настройка окупается за три-шесть месяцев, а основной измеримый эффект даёт снижение доли нарушений SLA по приоритетным линиям.
AI для клиентского сервиса: другие направления
Смежные задачи, которые обычно решаются в одном проекте с этой.
Разберём, где ваша очередь обращений теряет время
Покажите текущие каналы, объём заявок и используемую helpdesk-систему — предложим схему маршрутизации и сроки внедрения.