Пропущенный звонок: как проверить, был ли после него успешный ответ клиенту

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

Отделите событие от вывода

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

Но даже корректная последовательность не доказывает, что вопрос клиента решён. Для этого нужны договорённости и результат работы. Автоматизация помогает выбрать случаи для контроля, сохраняя границы данных.

Настройка телефонии, очередей и регистрации звонков рассмотрена в статье о телефонии Битрикс24. Проверка события не исправит сбой исходной регистрации.

Как настроить контроль конкретного пропуска

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

Для учебного лида подготовьте такие значения:

ID нужен именно из статистики телефонии, а не ID дела таймлайна. Момент проверки не должен быть в будущем. Исходный пропуск должен иметь входящий тип 2 или 3, код 304 и нулевую длительность.

В учебных данных пропуск начался в 12:00. Успешный исходящий тому же номеру начался в 12:10: тип 1 или 4, код 200, положительная длительность, та же прямая CRM-привязка. При проверке в 12:30 ожидается state=callback, найденный ID и delaySeconds=600. Это ожидаемый пример, а не выполненный здесь звонок.

Без исходящего при проверке в 12:15 ожидается awaiting: 30-минутное окно ещё открыто. После окончания окна без ответа ожидается none. Для awaiting назначьте следующую проверку позже; none используйте для разбора пропуска только после завершения окна.

Проверьте несколько последовательностей

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

1. Пропущенный звонок и подходящий успешный ответ после него.
2. Пропуск без последующего ответа.
3. Успешный звонок до пропуска.
4. Несколько пропусков и один более поздний ответ.
5. Недоступная запись или недостаточные права.

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

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

Что делать с результатом

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

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

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

Как учитывать время и доступ

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

Проверьте статус выполнения и пояснение ошибки перед чтением state. Действие требует полной выборки до 1000 звонков; неполные данные или неизвестный номер дают ошибку, а не none. Номер сравнивается по 6–15 цифрам с необязательным плюсом; региональные префиксы не исправляются. Косвенная связь через другую карточку не заменяет требуемую прямую привязку.

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

Почему это не оценка менеджера

Успешное соединение и качество обработки обращения относятся к разным вопросам. Разговор мог состояться, но клиент всё ещё ждёт документ. И наоборот, проблему могли согласованно решить другим каналом.

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

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

Частые вопросы