Первый ответ в чате: как учесть диалоги, которым ещё не ответили

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

Согласуйте, какое событие считается ответом

В этом разборе первый ответ — первое публичное сообщение живого оператора после первого входящего сообщения клиента. Уведомление «Мы получили обращение», действие бота, назначение ответственного и внутренняя заметка не останавливают этот счётчик. Готовый текст, отправленный человеком публично, может считаться ответом; содержательное качество такого текста проверяется отдельно.

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

Почему быстрый недавний диалог тоже исключён

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

В примере подходят A, B и D. Из них только A получил ответ не позже пяти минут: доля равна одной трети, примерно 33,33%. Диалог C появится в такой оценке, когда для него будет наблюдаться полное выбранное окно. Это специально заданная методика для сопоставимого среза, а не универсальное определение SLA.

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

По A, C и D известны ожидания 3, 1 и 7 минут. Среднее составляет 3 минуты 40 секунд. Это правильное описание этих трёх ответов, но оно ничего не сообщает о том, когда ответят B. Подстановка нуля вместо отсутствующего ответа сделала бы показатель лучше без изменения работы поддержки.

Ответ получен

Можно измерить промежуток до первого публичного сообщения человека.

Ответа ещё нет

Известен только возраст ожидания на момент среза; окончательная задержка может вырасти.

Полное окно наблюдалось

Обращение участвует в выбранной доле ответов не позже цели.

Обращение слишком недавнее

Его состояние видно в таблице, но в этой доле оно пока не участвует.

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

Как подготовить события для инструмента

1. Используйте обезличенные ключи диалогов. Если объединяете каналы, сделайте ключи различными, например WEB-A и TG-A.
2. Внутри каждого диалога укажите уникальный порядковый номер события из известной последовательности источника.
3. Проставьте роль: client — клиент; agent — подтверждённый публичный ответ человека; bot — автоматизация; note — внутренняя заметка; system — служебное событие.
4. Передайте время UTC с точностью до секунды и отдельно задайте момент среза.
5. Сверьте, что история содержит начало обращения. Кусок переписки из середины инструмент не сможет превратить в полную историю.

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

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

Что обсудить при подключении первой линии

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

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