Тикет стоит в «ожидании клиента»: когда SLA должен идти, а когда — останавливаться

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

Сначала назовите измеряемое обязательство

Время первого содержательного ответа и время решения — разные показатели. Автоматическое «мы получили сообщение» не стоит без объяснения выдавать за ответ специалиста. Пауза, уместная для решения после запроса необходимых сведений, может быть совершенно неуместна для первого ответа. У каждого показателя нужны собственные начало, конец и допустимые остановки.

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

Статус не должен быть способом спрятать работу

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

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

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

Пересекающиеся паузы вычитают один раз

Два источника могли записать ожидание с 12:00 до 13:00 и с 12:30 до 13:30. Вычитание двух полных часов будет ошибочным: реально перекрыто полтора часа. Сначала объединяют интервалы, затем пересекают их с рабочим календарём и временем жизни обращения.

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

Небольшой расчёт для одного рабочего дня

В примере тикет поступил в 10:00, проверка проводится в 16:00, рабочее окно — с 09:00 до 18:00. Пауза с 12:00 до 13:30 даёт 270 минут учтённой обработки вместо 360 календарных. При учебном бюджете 240 минут превышение составит 30 минут. Эти числа не являются тарифом или обещанием студии.

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

Приёмка на переписке, а не только на таймере

1. Создайте учебное обращение и сохраните все времена событий.
2. Добавьте обоснованную паузу, затем ответ клиента и возврат в обработку.
3. Проверьте перекрывающиеся остановки и обращение до начала смены.
4. Передайте тикет инженеру: общий возраст и назначенный владелец должны остаться понятными.
5. Сравните расчёт с самой перепиской и попросите оператора объяснить каждое вычитание.

Работающий SLA показывает не только итоговое нарушение, но и его происхождение. Такой отчёт помогает улучшать поддержку; счётчик, который можно остановить произвольным статусом, лишь делает задержки менее заметными.