Есть обещание. Есть нарушенное обещание. И есть ещё одна дата, которую компания называет после нарушения. Почему‑то именно третья часть часто исчезает из отчётности.
Например, Клиенту сказали: «ответим завтра до 18:00». Компания не успевает и сообщает: «вернёмся через два дня». Первичный SLA уже нарушен. Но дальше возможны два совершенно разных опыта.
В первом новый срок выполняют — Клиент хотя бы снова получает управляемость. Во втором не выполняют и его — возникает то, что я называю двойным обманом.
Поэтому повторный срок нужно считать отдельным обещанием и отдельным SLA.
Перенос не исправляет первое нарушение
Важно не подменить смысл. Сообщение о новом сроке не делает первый срок выполненным. В отчёте должны остаться оба факта:
- первоначальное обещание нарушено;
- пересмотренное обещание выполнено или нарушено.
Если после переноса просто заменить дату в системе, история станет зелёной. Для Клиента она не станет зелёной. Он помнит первое обещание, а управленческая система — уже нет.
Минимальный набор метрик
Я бы разделил контур обещаний минимум на шесть показателей.
1. Точность первичного обещания
SLA1 = кейсы, завершённые к исходному сроку / все кейсы с исходным сроком.
Это базовая дисциплина. Она не должна растворяться после изменения даты.
2. Доля переносов
Transfer rate = кейсы с изменённым сроком / все кейсы с обещанным сроком.
Сама по себе доля не говорит, хорошо или плохо работает сервис: причины и сложность кейсов различаются. Но динамика и разрез по причинам показывают, где первичное обещание системно нереалистично.
3. Своевременность предупреждения
Сколько переносов сообщено до истечения исходного срока. Сообщение после дедлайна — это уже объяснение нарушения, а не управление ожиданием.
4. Точность второго обещания
SLA2 = кейсы, выполненные к первому пересмотренному сроку / кейсы, где был назван первый пересмотренный срок.
Именно эту долю я предлагал считать в своём Telegram‑наблюдении о «второй дате».
5. Число обещаний на один кейс
Один перенос и пять переносов — разный опыт даже при одинаковом финальном результате. Полезно видеть распределение: без переноса, один, два, три и более.
6. Длительность и просрочка
Нужны не только доли выполнения, но и фактическое время до решения, величина просрочки и длина каждого нового обещания. Иначе метрику легко «улучшить», называя далёкие безопасные даты.
Как не превратить SLA2 в игру
Любая метрика начинает портиться, когда становится целью без ограничений. Для повторного срока нужны защитные показатели.
- Не стирать исходную дату. Хранить версионную историю обещаний.
- Не считать перенос исполнением. Это отдельное событие, а не закрытие SLA1.
- Контролировать длину новой даты. SLA2 нельзя улучшать обещанием «когда‑нибудь в следующем месяце».
- Считать повторные переносы. Третье обещание не должно растворять второе.
- Разделять причины. Клиент ожидает документы, компания ожидает Клиента, зависимость от партнёра, внутренний дефицит ресурса — это разные контуры.
- Сохранять результат. Формально своевременный ответ без решения не равен выполненной задаче.
Система качества должна видеть не один зелёный процент, а результат, доступность, исполнение и восприятие. Эту рамку я подробнее описал в статье
«Качество контактного центра — это формула».
Что должно быть в карточке кейса
Минимально полезная модель данных выглядит так:
- дата и время создания;
- исходный обещанный срок;
- фактический результат и время;
- дата решения о переносе;
- время уведомления Клиента;
- новый срок и его версия;
- причина переноса;
- владелец следующего шага;
- число повторных переносов;
- оценка или комментарий Клиента, если они собраны.
Если поле «срок» в системе одно и перезаписывается, честно посчитать обещания уже невозможно. Это архитектурная проблема, а не ошибка аналитика.
Как разбирать причины
Я бы начинал с массовых когорт: продукт, тип обращения, подразделение, партнёр, сегмент, причина, этап пути. Дальше задавал бы четыре вопроса.
- Исходный срок был реалистичен при известных условиях?
- Компания увидела риск заранее или только после нарушения?
- Кто имел право назвать новую дату и на каких данных?
- Что помешало выполнить второе обещание?
Причина часто находится не на первой линии. Это может быть очередь бэк‑офиса, отсутствие статуса от логистики, неверный справочник, зависимость от подрядчика, недоступные полномочия или правило, которое обещает быстрее, чем способен процесс.
ISO 10002:2018 рассматривает работу с жалобами как управляемый процесс, который нужно проектировать, эксплуатировать, анализировать и улучшать. Стандарт не задаёт метрику SLA2; это моя практическая надстройка для контроля повторного обещания внутри такого процесса.
Не нужен один норматив на все вторые сроки
Я не предлагаю универсальный целевой процент SLA2 или единый допустимый перенос. Значение зависит от типа обязательства, закона, договора, риска, продукта и реальной управляемости внешних зависимостей. Юридический срок нельзя заменить внутренней сервисной договорённостью, а внутреннее обещание не должно противоречить обязательным требованиям.
Для управления полезнее сначала разделить кейсы:
- компания полностью контролирует решение;
- результат зависит от другого подразделения;
- есть внешний партнёр или поставщик;
- компания ожидает действие или документы Клиента;
- срок определён законом или договором;
- срок назван сотрудником как сервисное обещание.
Так становится видно, где нужно исправить прогноз, где — интеграцию и эскалацию, а где — саму коммуникацию. Но внешняя зависимость не должна превращаться в бесконечное «мы ждём». У Клиента всё равно остаются отношения с вашей компанией, поэтому владелец следующего шага и дата следующего контакта нужны всегда.
Что видит Клиент
Правильное уведомление о переносе должно вернуть управляемость. В нём нужны:
- признание факта изменения;
- понятная причина без внутреннего жаргона;
- конкретный новый срок;
- что уже сделано и что произойдёт дальше;
- канал для уточнения, если риск для Клиента вырос.
Не обязательно писать длинное извинение. Важнее не оставлять человека в неопределённости и второй раз выполнить то, что пообещали.
Итак
Перенос срока — не административное редактирование поля. Это новое обещание после уже нарушенного обещания.
Сохраняйте историю, отдельно считайте SLA1 и SLA2, измеряйте своевременность предупреждения, количество переносов и фактическое время решения. А главное — не позволяйте новой дате переписать старый клиентский опыт.