Скорость ответа в чате: как перестали спорить, кто ответил быстро

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

Нужна была не оценка «вежливо / невежливо», а время: сколько клиент ждал первого живого ответа и где в сделке пауза растянулась.

Поставили виджет «Скорость ответа в чате»: по переписке сделки он пишет четыре цифры в поля карточки.

Проблема

1. Скорость жила в голове руководителя. В отчёте amoCRM её не было.
2. Автоответ бота выглядел как мгновенная реакция, хотя человек подключался сильно позже.
3. Клиент часто писал пачкой. Если считать от последнего сообщения, ожидание занижается.
4. Разбор «кто тормозит» превращался в спор без общей цифры.
5. KPI и бонус нельзя было привязать к ожиданию: не к чему привязывать.

Цель

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

Решение

Виджет читает переписку в сделке и пишет в поля четыре значения в секундах:

• время до первого ответа сотрудника;
• среднее время ответа по диалогу;
• самый короткий ответ;
• самый долгий ответ.

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

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

Качество скрипта (представление, квалификация, следующий шаг) сюда не входило. Для этого отдельный контур — ИИ-анализ переписок. Здесь только время.

Как запускали

1. Проверили, что чаты сайта и мессенджеров уже лежат в сделке.
2. Зафиксировали норму отдела: какую цифру смотреть на планёрке в первую очередь. Взяли первый ответ и максимум.
3. Назвали поля и включили пересчёт.
4. Сверили несколько живых диалогов: лента сообщений и значение в поле совпали.
5. Отдали руководителю срез по полям. Цвет от нормы — на оперативной панели поверх тех же цифр: зелёный в пределе, жёлтый на грани, красный дольше.

Заявку сначала назначают живому менеджеру. Иначе «долгий ответ» висит на сделке без хозяина. Назначение — соседний контур, распределение сделок.

Что изменилось

У каждой сделки появилось время ожидания. Планёрка идёт от поля, а не от впечатления по двум перепискам.

Стало видно разницу между «бот ответил сразу» и «менеджер ответил через паузу».

Максимум в сделке показывает, где диалог замер, даже если среднее выглядит приемлемо.

Цифру можно выгрузить и положить в правило KPI. Бонус больше не зависит от того, кто громче сказал «я был на связи».

Почему это работает

1. Метрика в карточке. Не отдельная таблица, которую забывают заполнить.
2. Бот не рисует красивый SLA. Считается ответ человека.
3. Пачка сообщений не сокращает ожидание. Берётся первое сообщение серии.
4. Норма ваша. Виджет отдаёт секунды. Порог «хорошо / плохо» задаёт отдел.

Вывод

Скорость ответа в чате amoCRM — это поле сделки, а не ощущение на планёрке. Когда первый ответ, среднее, минимум и максимум лежат в карточке, руководителя больше не нужно убеждать, что «мы быстрые».

Как устроены сами метрики: статья про скорость ответа. Подключение виджета: Скорость ответа в чате от amoPROFI.

Если у вас тоже чаты в amoCRM, а скорость ответа пока на словах — разберём поля и норму на бесплатном аудите.