Стоит ли приостанавливать SLA в ожидании клиента

Электровелосипед привезли в мастерскую с неисправностью, но съёмное зарядное устройство осталось у клиента дома. Мастер не может провести обещанную проверку, пока клиент его не принесёт. Для такого ожидания можно честно приостановить нужный таймер обслуживания.

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

Приостанавливайте время только ради действия клиента

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

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

Microsoft описывает условия паузы SLA на уровне сущности, показателя и отдельного правила. Более точная настройка может переопределить общую. Это полезно, но один общий статус ожидания способен изменить несколько таймеров неожиданным для сотрудника образом. Связывайте паузу с конкретным показателем и состоянием.

Отличайте ожидание клиента от ожидания компании

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

Руководство Microsoft по таймеру SLA показывает, что при переводе обращения в режим ожидания экземпляр показателя становится приостановленным и сохраняет длительность паузы, а активное и прошедшее время остаются отдельными полями. Не копируйте настройку платформы вслепую. Сначала решите, какое обещание вы измеряете.

Так сотрудник не отвечает за время, которым действительно управляет клиент, а компания не скрывает собственную очередь и зависимости.

Фиксируйте паузу как проверяемое событие

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

Клиент должен понимать, что нужно и что произойдёт дальше. Веломастерская может попросить зарядное устройство, объяснить невозможность диагностики без него и подтвердить, что работа продолжится после получения. Фраза «пришлите больше информации» слишком расплывчата и не показывает, когда действие выполнено.

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

Возобновляйте работу без обнуления возраста

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

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

Если клиент не отвечает, применяйте прозрачное правило из политики закрытия обращений. Закрывайте только после сообщения о сроке и при отсутствии незавершённого действия компании. Молчание не доказывает, что проблема решена.

Измеряйте ожидание не скрывая его

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

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

Правило короткое. Приостанавливайте SLA только ради необходимого действия клиента. Во всех остальных случаях сохраняйте честное время компании.

Часто задаваемые вопросы

Когда SLA поддержки можно приостановить?

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

Нужно ли останавливать SLA в ожидании другой команды?

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

Что делать после ответа клиента?

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

Может ли автоматизация ставить SLA на паузу?

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