«Отвечаем в течение часа» звучит понятно, пока запрос не приходит вечером в пятницу. Клиент ждёт обычный час, менеджер считает рабочий, а отчёт останавливает таймер после автоматического уведомления. Все три стороны уверены, что договорились об одном.
Регламент срока ответа должен определять начало отсчёта, событие завершения, календарь и допустимые исключения. Отдельно описываются первый содержательный ответ, дальнейшие обновления и фактическое решение вопроса. Один показатель не может достоверно заменить все три.
Определите, какой результат обещаете
Первый ответ подтверждает, что обращение принято человеком в работу: понятна задача, сообщён следующий шаг либо задан конкретный уточняющий вопрос. Автоматическое «Ваше сообщение получено» можно отправлять отдельно, но в предлагаемом регламенте оно не завершает измерение содержательного ответа.
Обновление — сообщение о ходе работы, если окончательный результат ещё не готов. Оно содержит изменившиеся сведения или подтверждает согласованный следующий срок.
Решение — достигнутый результат по задаче: выдан расчёт, исправлена ошибка, подтверждена поставка либо дан окончательный обоснованный ответ. У разных категорий обращений будут разные признаки решения.
В документации Zendesk о первом ответе описан собственный показатель от создания тикета до первого публичного ответа агента. Наш внутренний критерий содержательного ответа строже; перед использованием готового отчёта нужно проверить, совпадают ли определения.
Зафиксируйте рабочий календарь
В условном примере команда принимает обращения с понедельника по пятницу, с 09:00 до 18:00 по московскому времени. Перерыв 13:00–14:00 не входит в обслуживаемые часы. Получается восемь рабочих часов в обычный день.
Выходные и отдельно установленные нерабочие дни исключаются. Если на практике дежурный отвечает в обед или вечером, это нужно отразить в другом календаре либо изменить основной. Календарь в отчёте должен совпадать с опубликованными условиями обслуживания.
Личное отсутствие конкретного менеджера не останавливает часы всей команды. Должен существовать заменяющий сотрудник. Иначе измеряется удобство исполнителя, а не обещание клиенту.
Не используйте название «час» без уточнения на странице контактов и в сообщении о приёме. Покупателю полезна конкретная ожидаемая дата ответа, особенно при запросе перед выходными.
Пример через выходные
Условный запрос поступил в пятницу в 17:40. Автоматическое уведомление отправлено в 17:41. Содержательный ответ менеджера клиент получил в понедельник в 09:30. Между этими днями нет дополнительных праздников.
Календарное ожидание составило 63 часа 50 минут. По рабочему календарю прошло 20 минут пятницы и 30 минут понедельника: всего 50 минут.
Если установлен целевой срок 60 рабочих минут, ответ укладывается. Крайний срок в этом примере — понедельник 09:40. Автоматическое уведомление не превращает результат в одну минуту.
Обе длительности полезны. Рабочие минуты проверяют соблюдение согласованного режима, календарное ожидание показывает опыт клиента. Большой разрыв между ними может подсказать необходимость другого покрытия, но не является арифметической ошибкой.
Пример с перерывом
Обращение поступило в понедельник в 12:50, ответ отправлен в 14:20. Календарно прошло 90 минут. По принятому графику: десять минут до 13:00 и двадцать после 14:00, итого 30 рабочих минут.
Если компания публично обещала непрерывный ответ в течение часа, такое исключение обеда недопустимо для проверки обещания. Нельзя задним числом выбирать календарь, который делает показатель красивее.
На этапе настройки вручную пересчитайте несколько пограничных случаев: конец смены, начало рабочего дня, обед, выходной и праздничный день. Эти примеры станут проверкой для любого будущего отчёта.
Когда разрешена пауза
Для первого ответа пауза «ждём клиента» обычно бессмысленна: чтобы запросить данные, команда уже должна ответить. Для срока решения ожидание необходимых сведений можно учитывать отдельно, если правило согласовано.
Пауза начинается после конкретного запроса недостающих данных и заканчивается при их получении. В карточке указано, чего именно не хватает. Фраза «ожидание» без объяснения не должна останавливать показатель.
В документации Zendesk о политиках SLA существуют разные измерения ответа и решения. Это подтверждает необходимость выбрать нужную метрику, а не переносить правила паузы с одного показателя на другой.
Внутреннее ожидание коллеги или согласования руководителя в предлагаемом регламенте не исключается из времени решения. Клиент передал задачу компании, поэтому внутреннюю задержку нужно видеть и улучшать.
Расчёт решения с ожиданием данных
Запрос поступил в понедельник в 10:00. В 10:30 сотрудник запросил необходимый номер заказа. Клиент прислал его в 14:30. В 15:00 вопрос решён. Используем тот же календарь с перерывом 13:00–14:00.
Общее календарное ожидание клиента — пять часов. Рабочее время от 10:00 до 15:00 без обеда — четыре часа.
Ожидание данных клиента заняло четыре календарных часа: с 10:30 до 14:30. В рабочих часах это 2,5 часа до обеда и 0,5 после, всего три часа.
Срок решения с разрешённой паузой равен 4 − 3 = одному рабочему часу. Он состоит из получаса до запроса данных и получаса после получения. Это время по сервисному правилу, а не доказательство, что сотрудник непрерывно трудился ровно час.
Отчёт должен сохранить и общий срок, и паузу. Показывать клиенту только один час без объяснения означало бы скрывать его фактическое пятичасовое ожидание.
Как считать выполнение обещания
Для оценки берите обращения, чей целевой срок уже наступил к моменту отчёта. Иначе новые запросы с ещё не закончившимся окном будут ошибочно считаться просроченными либо преждевременно успешными.
Пример: по 20 обращениям срок первого ответа уже наступил. На 17 ответили вовремя, на два — поздно, одно остаётся без ответа. Выполнение составляет 17 / 20 × 100 = 85%. Открытое просроченное обращение входит в знаменатель.
Дополнительно пять новых обращений ещё находятся внутри разрешённого часа. Их показывают отдельно, не добавляя к текущим 20. Когда срок наступит, они попадут в соответствующую оценку.
Среднее время только по отвеченным обращениям может выглядеть хорошим, пока самые старые остаются без ответа. Поэтому рядом нужны количество просроченных открытых и возраст самого старого.
Шаблон регламента
- Каналы и категории обращений.
- Рабочий календарь, часовой пояс, исключения.
- Событие начала и источник времени.
- Признак первого содержательного ответа.
- Цель первого ответа и правило следующих обновлений.
- Определение решения по каждой категории.
- Разрешённые паузы с началом, окончанием и основанием.
- Ответственный, замена и порядок эскалации.
- Формула отчёта и примеры пограничных случаев.
Заполненная формулировка: «Стандартный запрос расчёта: первый содержательный ответ до 60 рабочих минут. Если расчёт требует дополнительных данных, менеджер указывает перечень и следующую дату связи. Ожидание клиента фиксируется отдельно; время внутреннего расчёта не исключается».
Проверьте исполнимость правила
Перед публикацией срока изучите поток по часам и доступность команды. Если один человек регулярно получает несколько сложных запросов одновременно, обещание короткого ответа требует организационного решения.
Проведите ограниченный пилот, проверьте ручной расчёт на нескольких обращениях и согласуйте замену отсутствующего сотрудника. Распределение ответственности разобрано в статье о назначении входящих заявок.
В ЧатПлюс заявлены единые входящие, CRM, проекты и задачи. Поддержку сервисных календарей, таймеров и отчётов нельзя предполагать по этому перечню: её нужно уточнить. Обсудите учёт заявок и работу команды, приложив регламент и три контрольных примера расчёта.
Источники
- Zendesk: Understanding ticket reply time — Различие первого ответа и расчёта показателя в рабочих часах.
- Zendesk: Defining SLA policies — Отдельные цели времени ответа и решения, выбор правил измерения.