SLA обработки лидов в CRM: сроки, эскалация и контроль

SLA обработки лидов в CRM — это договорённость о том, как быстро команда принимает новую заявку и когда клиент получает осмысленный ответ. Без точного определения события «ответили» отчёт легко сделать красивым: робот мгновенно отправит шаблон, а реальный разговор начнётся через день. Поэтому регламент должен описывать и таймер, и качество действия.

Владелец процесса обычно думает в терминах «не потерять горячего клиента». Менеджеру нужны конкретные правила: какую заявку брать первой, что делать при занятости коллеги, как поступать после неудачного звонка. CRM соединяет обе задачи, если каждый переход оставляет след: время поступления, назначение, попытка контакта, ответ и следующий шаг.

Что именно считать нарушением SLA

Не смешивайте три разных срока. Время назначения — от попадания заявки в систему до появления ответственного. Время первого действия — до первого звонка, сообщения или обработки в очереди. Время первого содержательного ответа — до контакта, после которого клиент понимает, что запрос прочитан и что произойдёт дальше. Для разных каналов последний показатель измеряется по-разному: звонок может остаться без ответа, а сообщение — быть доставленным без прочтения.

Полезно хранить три временные метки отдельно. Тогда руководитель видит, где задержка: интеграция поздно доставила заявку, очередь не назначила владельца или назначенный человек не связался с клиентом. Общий показатель «скорость реакции» скрывает эти причины.

Когда запускать и останавливать таймер

Точкой старта должно быть событие, которое можно проверить: время отправки формы или поступления звонка в источник, а также время получения CRM. Разница между ними показывает задержку интеграции. Если доступна только дата создания сделки, в отчёте честно указывают ограничение измерения. Нельзя перезапускать таймер при смене ответственного: клиент ждёт с момента обращения, а не с момента последней передачи.

Для графика работы задайте календарь с часовым поясом, сменами, выходными и праздниками. Утренние заявки часто попадают в один всплеск; распределение нагрузки должно учитывать этот факт. Отдельно решите, работает ли SLA в нерабочее время. Например, сообщение в 23:00 может получить автоматическое подтверждение с указанием часов работы, а отсчёт человеческого ответа начнётся в 09:00. Если на сайте обещан круглосуточный ответ, нужна дежурная команда, а не только настройка таймера.

Паузы должны быть узкими и проверяемыми. Ожидание ответа клиента после первого контакта можно вывести в другой статус. Занятость менеджера, отпуск без подмены или «не успели разобрать» не должны обнулять SLA. Иначе метрика перестанет отражать клиентский опыт.

Приоритеты без субъективного «срочно»

Один срок для всех обращений удобен в таблице, но редко полезен в работе. Заявка на срочную консультацию, просьба прислать презентацию и технический вопрос существующего клиента требуют разной обработки. Задайте 2–3 класса, которые CRM может определить из канала, продукта, сегмента и ответа формы. Сложная матрица с десятками исключений быстро становится неуправляемой.

Класс важен только вместе с действием. Для высокого приоритета может быть отдельная очередь и подмена при отсутствии владельца. Для обычного — ближайшая доступная смена. Для некорректного контакта — проверка и отдельный исход. Не приравнивайте «дорогой источник» к «качественному лиду»: стоимость рекламы и готовность клиента купить — разные признаки. Подробнее о критериях есть в материале про квалификацию лидов в CRM.

Кто владеет заявкой до первого ответа

Владелец должен появляться автоматически либо очередь должна иметь дежурного. Правило «новые лиды видят все» создаёт коллективную безответственность. В CRM стоит хранить исходного владельца, время передачи и причину смены. Для распределения подходят смены, география, продукт, загрузка и компетенции; выбор зависит от реального процесса, а не от числа доступных полей.

Продумайте случаи, которые ломают идеальный сценарий: сотрудник в отпуске, лид пришёл за минуту до конца смены, контакт уже ведёт другой менеджер, заявка попала в неверную воронку. Правила подмены и повторного назначения должны сохранять историю. Если источник отправил дубль, новый таймер не должен подменять старый без проверки связи с предыдущим обращением. Про качество данных CRM полезно подумать до автоматизации.

Эскалация: сигнал, подмена, разбор причины

Эскалация — это не бесконечная серия уведомлений. Сначала предупредите владельца до дедлайна, затем передайте заявку дежурному или руководителю при реальном риске, а после нарушения зафиксируйте причину. Если уведомление не меняет действие, оно только создаёт шум. Хорошая схема ограничивает частоту сигналов и имеет понятного получателя на каждом уровне.

Пример логики: после назначения менеджер получает задачу с крайним сроком; ближе к порогу CRM проверяет, был ли контакт; при отсутствии действия заявка попадает на экран дежурного; после просрочки руководитель видит карточку с каналом, владельцем и этапом задержки. Конкретные минуты назначают после изучения нагрузки и ожиданий клиентов, а не копируют из чужого кейса.

Какие отчёты показывают проблему

Среднее время ответа удобно, но несколько очень долгих задержек скрываются за большим числом быстрых ответов. Вместе со средним смотрите медиану, 90-й процентиль (P90), долю заявок в SLA и число вообще не обработанных обращений. Разбивайте данные по каналу, часу поступления, команде и классу приоритета. Для коротких периодов показывайте также количество заявок: процент от трёх обращений вводит в заблуждение.

Свяжите скорость с исходом: контактность, квалификация, назначенные встречи и продажи. Если команда отвечает мгновенно бессодержательным шаблоном, SLA улучшается, а качество может падать. Выборочная проверка разговоров и переписки нужна как противовес одной цифре. В отчёте отмечайте технические ошибки доставки отдельно от ошибок работы менеджеров.

Порядок внедрения без остановки продаж

1. Снять базуЗафиксировать время событий за последние недели и найти задержки по каналам.
2. Описать словарьСогласовать старт, ответ, рабочие часы, паузы и исключения.
3. Назначить владельцевПроверить смены, подмену и обработку дублей.
4. Включить сигналыСначала в тестовом режиме, затем с ограниченной эскалацией.
5. Разбирать отклоненияЕженедельно менять процесс по фактам, сохраняя историю правил.

Пилот лучше проводить на одном потоке с понятным объёмом. Зафиксируйте исходные значения до запуска и проверяйте не только долю попаданий в срок, но и нагрузку на сотрудников. При чрезмерно жёстком пороге сотрудники начинают отмечать фиктивные действия; это признак плохого дизайна регламента, а не аргумент отменить контроль.

Типичные ошибки настройки

Главная ошибка — считать автоответ реальным контактом. Вторая — запускать SLA только после ручного создания сделки, теряя время до импорта. Третья — ставить одинаковые правила для ночных и дневных смен, хотя обещания клиентам разные. Четвёртая — уведомлять руководителя о каждой заявке без понятного способа вмешаться. Пятая — показывать красивый процент без списка конкретных просрочек.

Регламент должен быть доступен менеджеру прямо из рабочего процесса. Если в нём написано «ответить быстро», система не подскажет, что делать. Формулируйте проверяемо: событие, ответственный, срок, допустимый результат и действие при исключении. Более общий каркас описан в статье про регламент отдела продаж в CRM.