Пропущенный звонок нельзя считать обработанным только потому, что сотрудник позже набрал номер или телефония зарегистрировала соединение. Руководителю нужны два независимых признака: технический результат каждого вызова и бизнес-результат всего обращения.
Практическое правило: подходящий пропуск создаёт одну задачу перезвона. Повторные вызовы дополняют эту задачу, а закрывает её не очередной телефонный статус, а согласованный результат, сохранённый в CRM. Такой учёт помогает не путать два пропуска с двумя клиентами и не терять обращение между сотрудниками.
Какой звонок считать необработанным
Телефония регистрирует отдельные события: входящий вызов, соединение, занято, отсутствие ответа или ошибку. Бизнес учитывает обращение клиента: выяснил ли сотрудник причину звонка, зафиксировал ли итог и назначил ли следующее действие. Эти уровни связаны, но не равны друг другу.
Например, короткий разговор мог состояться, но оборваться до выяснения вопроса. И наоборот, клиент мог за несколько секунд сообщить, что вопрос уже неактуален. Поэтому длительность сама по себе не определяет результат.
| Технический результат | Что он означает для очереди | Что нужно проверить |
|---|---|---|
| Не ответили | Кандидат на создание или обновление задачи перезвона | Есть ли уже открытая задача по подтверждённому обращению |
| Занято | Отдельный результат попытки, а не состоявшийся контакт | Нужна ли ещё одна попытка и когда её выполнять |
| Ошибка соединения | Повод проверить канал или данные вызова | Было ли реальное обращение клиента и можно ли безопасно повторить звонок |
| Соединено | Разговор технически состоялся | Записан ли бизнес-результат в CRM |
| Короткий разговор | Не является автоматически ни пропуском, ни обработкой | Какой итог зафиксировал сотрудник |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Для каждого результата заранее задают правило. Если вызов не принят, система ставит обращение в очередь. Если линия занята, применяется отдельный порядок повторной попытки. Если произошла техническая ошибка, событие направляют на проверку: оно само по себе не доказывает, что клиент пытался решить вопрос.
Обработанным стоит считать обращение, по которому сотрудник подтвердил контакт и сохранил согласованный итог: например, «обращение принято в работу», «клиент отказался» или другой результат из правил компании. Статус «соединено» без такого итога недостаточен.
Какие события получать от телефонии
Для контроля нужен журнал, в котором каждое событие можно найти и сопоставить с CRM. Минимальный набор данных:
- идентификатор звонка;
- дата и время с часовым поясом;
- направление: входящий или исходящий;
- технический результат и причина завершения;
- идентификатор ответственного сотрудника, если он известен;
- нормализованный номер или другой точный идентификатор стороны;
- связанный объект CRM, если связь уже установлена.
В Битрикс24 историю звонков можно получать документированным методом REST API voximplant.statistic.get. В официальной документации Битрикс24 указаны, среди прочего, поля CALL_ID, CALL_START_DATE, CALL_TYPE, PORTAL_USER_ID, PHONE_NUMBER, CALL_FAILED_CODE, CALL_FAILED_REASON, а также идентификаторы связанных объектов CRM. Метод относится к области телефонии и возвращает список звонков из её статистики.
Это описание документированной последовательности, а не отчёт о запуске метода в конкретном портале. Перед подключением нужно проверить доступные поля и ответы именно в системе заказчика. Для выполнения метода интеграционному пользователю требуется право просмотра статистики звонков. Результаты выдаются постранично: в документации указан размер страницы 50 записей, поэтому полную историю нельзя считать полученной после чтения только первой страницы.
Поле телефонного результата не заменяет бизнес-статус. Интеграция может перенести в журнал код пропуска или успешного звонка, но правило компании должно отдельно решить, создавать ли задачу и какое событие разрешает её закрыть.
Как поставить пропуск в очередь перезвона
Первое подходящее событие создаёт одну связанную задачу. В ней сохраняют идентификатор исходного звонка, время обнаружения, ответственного, срок реакции и ссылку на объект CRM. Следующее событие того же подтверждённого обращения дописывают в историю задачи, а не превращают во второй параллельный перезвон.
Это правило должно быть идемпотентным: повторная доставка одного и того же события с тем же идентификатором не создаёт новую задачу. Однако совпадение части номера или внешне похожие номера недостаточны для объединения. Иначе система может связать разных людей.
Если клиент неизвестен, можно создать запись со статусом «личность не подтверждена» и сохранить точный технический идентификатор события. После разговора сотрудник уточняет связь с CRM. До подтверждения нельзя автоматически приписывать вызов существующему человеку только по похожему номеру.
Срок реакции считают с учётом рабочего времени. Допустим, компания принимает такие задачи с 09:00 до 18:00, а норматив реакции равен 15 минутам. Пропуск обнаружен в 10:02, значит:
due_at = 10:02 + 15 минут = 10:17.
Это учебное правило, а не универсальный норматив. Компания должна установить свой интервал и срок. Если событие поступило после окончания рабочего дня, отсчёт можно начать от следующего рабочего интервала. Нужно отдельно согласовать выходные, праздники и ситуацию, когда срок пересекает конец смены.
В задаче полезно хранить:
- исходное событие и все связанные попытки;
- ответственного за следующий шаг;
- ближайший срок действия;
- допустимые основания закрытия.
Так очередь отвечает не только на вопрос «сколько было пропущенных звонков», но и показывает, по каким обращениям ещё требуется действие.
Как учитывать повторные попытки и состоявшийся контакт
Повторный входящий звонок связывают с открытой задачей, когда система располагает точным техническим идентификатором стороны и подтверждённой связью с CRM. Одного сходства номеров недостаточно. Если связь не подтверждена, событие оставляют для уточнения.
Если на повторный звонок ответил другой сотрудник, он работает с общей задачей обращения. Первая задача не должна оставаться открытой только потому, что контакт состоялся не у первоначально назначенного менеджера. Сотрудник сохраняет результат в CRM, после чего система проверяет согласованное основание закрытия.
Закрывающее событие состоит из двух частей:
- разговор с клиентом подтверждён;
- бизнес-результат разговора сохранён в CRM.
Сам статус «соединено» задачу не закрывает. Он не показывает, успел ли сотрудник выяснить вопрос, договорился ли о следующем шаге и сохранил ли итог.
Отказ клиента — полноценный результат контакта, если сотрудник зафиксировал его по правилам компании. Недоступность связи результатом разговора не является. После неудачной исходящей попытки задача остаётся открытой до следующей попытки, достижения согласованного лимита или другого заранее определённого итога. Лимит и действие после его достижения нужно закрепить в регламенте: статья не задаёт их вместо компании.
Учебная история одного пропущенного обращения
Ниже — синтетический пример, а не кейс клиента и не результат внедрения Switch On AI. Идентификаторы и время придуманы для объяснения правил; реальные телефонные номера не используются.
Условный клиент дважды не дозвонился. На третий входящий вызов ответил другой сотрудник. Все три события относятся к одному подтверждённому контакту CRM, поэтому система ведёт одну задачу перезвона.
| Время | call_id | Направление | Технический результат | Ответственный | CRM-связь | task_id | Бизнес-результат | Состояние очереди |
|---|---|---|---|---|---|---|---|---|
| 10:02 | C-001 | Входящий | Не ответили | A | Контакт K-001 подтверждён | T-001 | Результата разговора нет | Создана одна задача, срок 10:17 |
| 10:08 | C-002 | Входящий | Не ответили | A | Тот же контакт K-001 | T-001 | Результата разговора нет | Событие добавлено в T-001, новая задача не создана |
| 10:15 | C-003 | Входящий | Ответил сотрудник B | B | Тот же контакт K-001 | T-001 | До записи результата задача открыта | Ожидается итог разговора |
| 10:17 | Запись в CRM | — | — | B | Контакт K-001 | T-001 | Контакт подтверждён, обращение принято в работу | T-001 закрыта |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Обязательная сводка показывает различие между событием и обращением:
| Событие | Статус обращения | Ответственный | Основание закрытия |
|---|---|---|---|
| C-001: первый пропуск | Открыто, создана T-001 | A | Основания нет |
| C-002: повторный пропуск | Открыто, обновлена T-001 | A | Основания нет |
| C-003 и запись результата в 10:17 | Обработано | B | Подтверждённый контакт и сохранённый результат «обращение принято в работу» |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Итог учебной истории:
- телефонных событий — 3;
- зарегистрированных пропусков — 2;
- уникальных подтверждённых клиентов — 1;
- созданных задач — 1;
- подтверждённых контактов — 1;
- открытых задач после 10:17 —
1 − 1 = 0.
Два пропуска не означают двух клиентов или двух задач. Формула состояния очереди здесь проста: открытые задачи на конец = созданные задачи − задачи, закрытые подтверждённым результатом.
Как проверять обработку и подключить автоматизацию
Очередь проверяют трёхсторонней сверкой. Журнал телефонии подтверждает каждое событие по call_id. CRM показывает связанный контакт и записанный результат. Журнал задач показывает создание, обновления и закрытие по task_id. Если одна из частей отсутствует, руководитель видит разрыв процесса.
Для учебной истории сверка выглядит так:
| Источник | Что должно быть найдено | Контрольный итог |
|---|---|---|
| Телефония | C-001, C-002 и C-003 | 3 телефонных события |
| CRM | K-001 и результат, сохранённый сотрудником B | 1 контакт и 1 бизнес-результат |
| Очередь | Создание и закрытие T-001 | 1 задача, после 10:17 открытых задач нет |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Перед запуском автоматизации полезно провести пилот на обезличенной выборке. В него включают обычный пропуск, повтор одного события, несколько звонков одного клиента, неизвестного клиента, ответ другого сотрудника, отказ, недоступность связи и техническую ошибку. Ожидаемое действие записывают до проверки.
Критерии пилота можно считать так:
- заполненность событий = события со всеми обязательными полями / все события;
- связь пропусков с задачами = подходящие пропуски с
task_id/ все подходящие пропуски; - корректность закрытия = задачи, закрытые подтверждённым результатом / все закрытые задачи.
На синтетических данных выше арифметика даёт 3/3 = 100%, 2/2 = 100% и 1/1 = 100%. Это результат заранее составленного учебного примера, а не измерение реальной интеграции и не обещание показателей после внедрения. В пилоте значения нужно получить на фактической выборке и разобрать каждое расхождение.
Автоматизация этого процесса — обычная интеграция между телефонией, CRM, задачами и уведомлениями. Она не становится ИИ-агентом только потому, что переносит события и применяет заданные правила. ИИ может понадобиться для отдельной задачи, например для работы с неструктурированным содержанием разговора, но это уже другой сценарий.
Switch On AI может помочь спроектировать связь событий телефонии, задач CRM и уведомлений для аналогичного процесса. Состав интеграции зависит от платформы, доступных прав и правил обработки обращений. На странице помощника для продаж описан подход к передаче обращений в CRM и проверке повторов; для этой задачи сначала нужно определить, достаточно ли обычной интеграции без ИИ.
Чтобы обсудить процесс, подготовьте обезличенный журнал пропусков, рабочее время, срок реакции, основания закрытия и роли сотрудников. Затем покажите текущий порядок перезвона: по нему можно определить границы прототипа и критерии приёмки. Если нужно отдельно разбирать содержание состоявшихся разговоров, смотрите материал о расшифровке звонков и CRM.
Вопросы по этой задаче
Как понять, что пропущенный звонок обработан?
Обращение обработано, когда сотрудник подтвердил контакт и сохранил в CRM согласованный бизнес-результат. Статус «соединено» или выполненная попытка перезвона сами по себе этого не доказывают.
Как не создавать несколько задач одному клиенту?
Первый подходящий пропуск создаёт одну задачу, а повторные события дописываются в неё по уникальным идентификаторам и подтверждённой связи с CRM. Нельзя объединять людей только по частичному совпадению или сходству номеров.
Нужно ли автоматически перезванивать ночью?
Это определяет регламент компании. Безопасное базовое правило — учитывать рабочее время и переносить срок реакции на начало следующего рабочего интервала. Выходные, часовые пояса и срочные обращения нужно согласовать отдельно.
Можно ли закрыть задачу после ответа другого сотрудника?
Да, если этот сотрудник подтвердил контакт и сохранил согласованный результат в CRM. Общая задача обращения закрывается по результату, а не по личности первоначально назначенного сотрудника.