SLA по обработке заявки: сколько времени — нормально, а сколько — потеря клиента

Правило обработки заявки, которое часто называют SLA, определяет, какое действие отдел должен выполнить после обращения, от какого события считать срок и кто разбирает отклонение. Для продаж это способ сделать очередь управляемой. Без этих уточнений фраза отвечаем быстро не позволяет ни проверить работу, ни понять причину задержки.

Нет универсального количества минут, после которого любой клиент потерян. На ожидания влияют срочность запроса, канал, рабочее время и характер покупки. Разумнее выбрать первоначальную норму по своему процессу, проверить возможность её выполнять и наблюдать результат. Здесь речь о внутреннем порядке отдела, а условия обязательств перед клиентами определяются отдельно.

Сначала определите, что считается реакцией

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

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

Опишите результат простым проверяемым предложением: сотрудник прочитал обращение, проверил контекст и выполнил согласованное действие. Затем укажите, какое свидетельство остаётся в CRM. Наличие ответственного в карточке не всегда означает, что он уже приступил к работе. Связь между этапами и действиями должна быть понятна в настроенной воронке, а не жить только в объяснениях руководителя.

Зафиксируйте начало и конец отсчёта

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

Сохраните обе исходные отметки, если доступна такая возможность: когда обращение возникло и когда стало доступно отделу. Тогда разрыв можно объяснить, а не списывать на медленную работу человека. Для окончания выберите ранее определённое действие. Изменение статуса карточки подходит только тогда, когда оно действительно связано с этим действием и не выполняется автоматически раньше реальной реакции.

В amoCRM и Битрикс24 реализация зависит от конкретного сценария, интеграции, прав и доступных инструментов. Поэтому сначала описывают смысл событий, а затем проверяют, где брать их время и как оно сохраняется при передаче обращения. Согласованный порядок распределения заявок помогает отделить ожидание в общей очереди от работы назначенного менеджера.

Укажите рабочий календарь и часовой пояс

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

Условный пример: отдел работает с 09:00 до 18:00, обращение пришло в 17:55, содержательный ответ дан на следующий рабочий день в 09:12. Между событиями прошло много календарного времени, но внутри указанного рабочего окна - семнадцать минут. Это пример расчёта, а не рекомендация по норме. Он верен только при выбранном правиле учёта и отсутствии других исключений в календаре.

Второе условное обращение поступает ночью. Если действующий порядок начинает отсчёт с открытия смены, это нужно видеть в расчёте. Если бизнес обещает реакцию в любое время, следует заранее обеспечить людей и процесс для такой модели. Нельзя задним числом выбирать удобный календарь для каждой просрочки. Условия полезно показывать сотруднику рядом с задачей, а не прятать в сложной таблице.

Выберите первоначальную норму по своим данным

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

Перед запуском замера согласуйте, кто разбирает спорные случаи и где фиксирует решение. Например, повторное сообщение в уже открытом диалоге может продолжать прежний запрос или начинать новый. Правило должно различать эти ситуации последовательно. Иначе разные сотрудники будут получать разные результаты просто из-за способа регистрации переписки, а обсуждение скорости превратится в спор о карточках.

Изучите распределение задержек, а не только среднее. Один быстрый ответ способен улучшить среднее значение, но не исправляет длинную необработанную очередь. Дополните его долей обращений, обработанных в согласованном окне, и отдельным списком ещё не получивших действия. Для поиска причин важен разрез по каналу, смене и нагрузке. Сравнивать людей без этого контекста преждевременно.

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

Назначьте владельца очереди и порядок эскалации

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

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

Для пропущенного звонка отдельно проверяют, появилась ли запись, кто отвечает за попытку связи и где виден результат. Сам факт пропуска в телефонной системе не описывает весь дальнейший маршрут. Полезно сопоставить правило обработки с настройкой телефонного маршрута. Необходимо проверять и действия программы, и решения людей: сбой одного звена не всегда виден в другом.

Отличайте реальную просрочку от ошибки измерения

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

Для доли соблюдения нормы заранее выберите отчётную выборку. Один понятный вариант - обращения, у которых к моменту отчёта уже закончилось допустимое окно реакции. В этой выборке остаются и своевременные, и поздние ответы, и всё ещё не обработанные просроченные обращения. Заявки, для которых окно ещё не закончилось, не подмешивают в этот показатель; их показывают отдельно как текущую очередь.

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

Меняйте правило вместе с процессом

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

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

Внедрённый порядок должен быть выполнимым другим сотрудником, а не только человеком, который его придумал. Для этого полезны короткая инструкция, пример спорного случая и практическая проверка. Обучение работе в CRM связывает настройки со смыслом действий, а сопровождение помогает организовать последующие изменения. Состав конкретных работ и условия реакции определяют отдельно.

Частые вопросы

Что сделать дальше

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

Итогом должен стать небольшой паспорт правила и понятный порядок проверки очереди. Начинать можно с диагностики текущего маршрута заявки. Хороший регламент не обещает, что клиент никогда не уйдёт; он помогает увидеть задержку, назначить действие и проверить, изменился ли процесс.