Менеджер увидел пропущенный звонок и перезвонил. Клиент не ответил. В отчёте появилась исходящая попытка, сотрудник переключился на следующую задачу, а вопрос клиента остался нерешённым. Формально действие выполнено; фактически контакт потерян. Автоматизация должна различать эти два результата.
Подключить телефонию к CRM недостаточно. Нужно определить, какие события попадают в очередь, кто обязан отреагировать и по какому признаку обращение перестаёт считаться необработанным. Рассмотрим устройство такого процесса для отдела продаж или поддержки. Это схема проектирования, которую настраивают под свою АТС и портал, а не универсальная функция одной кнопки.
Что Битрикс24 уже показывает, а что надо определить отдельно #
В CRM входящие и пропущенные звонки отражаются в делах и счётчиках. Штатный поиск помогает сотруднику найти карточки, требующие внимания; его поведение описано в документации Битрикс24 . Но бизнес-правило «клиент получил ответ по своему вопросу» нельзя вывести только из факта исходящего звонка.
Сначала фиксируют три понятия: событие телефонии, обращение клиента и попытку обработки. Один клиент может позвонить несколько раз по одной проблеме. И наоборот, через один общий номер компании могут обращаться разные люди по разным сделкам. Поэтому номер телефона — способ найти кандидатов, а не основание безусловно закрыть все обращения.
Для известного клиента ответственным может быть его менеджер. Для нового номера — сотрудник дежурной группы. Но эти правила должны учитывать отсутствие человека: отпуск, смену отдела, окончание рабочего дня. Запись на уволенного менеджера не должна оставаться вечным необработанным обращением.
Хорошая схема содержит основного исполнителя, резервную группу и момент передачи ответственности. Передача фиксируется в истории: кому назначили, почему и кто теперь должен действовать. Одновременное уведомление десяти сотрудников не заменяет назначения — каждый может решить, что клиентом уже занят коллега.
Отдельно учитывают линию, на которую позвонили. Продажи, сервис и бухгалтерия могут использовать разные очереди и сроки реакции. Не стоит отправлять вопрос по закрывающим документам первому свободному продавцу только потому, что номер найден в CRM.
Если клиент позвонил вечером, таймер реакции может начинаться с открытия следующей смены. Для круглосуточной поддержки, напротив, ночное обращение остаётся рабочим. Нужен календарь конкретной очереди, а не один общий интервал для всех подразделений.
Время первого действия и время успешной связи измеряют отдельно. Попытка через минуту и разговор на следующий день — разные показатели. Порог успешности нельзя задавать одной длительностью: длинное ожидание на линии ещё не доказывает разговор, а короткий звонок может содержать достаточный ответ.
Практический результат менеджера лучше выбирать из понятного списка: связались и решили, требуется повтор, неверный номер, обращение не по профилю. Для исключений нужны причина и право на завершение, чтобы сотрудник не убирал сложные звонки произвольным статусом.
Как не получить две задачи на один пропущенный вызов #
Интеграция сохраняет устойчивый идентификатор события АТС. При повторном получении события она находит уже созданную запись. Если поставщик передаёт разные события начала, окончания и результата вызова, их связывают по модели этого поставщика, а не создают три независимых обращения.
Ниже — условная внутренняя запись для обсуждения требований. Это не готовое тело запроса REST Битрикс24: имена полей и хранение выбирают при реализации.
Если вызов прошёл вне подключённой АТС или интеграция не передала его в CRM, приложение не сможет достоверно восстановить разговор. Поэтому сначала проверяют полноту событий: известный и неизвестный номер, перевод между операторами, очередь, отмену звонка и недоступность сотрудника. Только затем строят отчёт о работе менеджеров.
— Клиент дважды позвонил до перезвона: история сохранена, очередь не превратилась в несвязанные задачи.
— Менеджер перезвонил, но получил «занято»: следующее действие осталось запланированным.
— Клиент связался с другим сотрудником: обращение не закрыто автоматически без проверки вопроса.
— Исполнитель ушёл со смены: ответственность передана по правилу, а не потеряна.
— АТС повторила событие: второй экземпляр задачи не появился.
— Руководитель видит отдельно ожидание первого действия и ожидание результата.
Для пилота достаточно ограниченной группы и одной линии. Сверяют журнал АТС, дела CRM и записи очереди за один период. Расхождения разбирают по идентификаторам вызовов: простое сравнение общих чисел скрывает переводы и повторные попытки.
Да, если штатные дела и принятый порядок работы покрывают задачу. Дополнительная логика нужна, когда требуется связывать несколько попыток, учитывать разные календари, передавать ответственность и подтверждать результат. Сначала проверяют стандартный сценарий, затем определяют, чего именно ему недостаёт.
Почему нельзя считать любой исходящий успешным перезвоном? #
Исходящий вызов подтверждает попытку, но не разговор и не решение вопроса. Состав итоговых статусов согласуют с отделом: иначе система будет поощрять набор номера вместо обработки обращения.
Если звонки фиксируются, а клиенты всё равно остаются без ответа, NetLab поможет проверить интеграцию Битрикс24 с IP-телефонией , сопоставить события АТС и CRM и настроить очередь перезвонов. Оставьте заявку : укажите оператора телефонии, число линий и пример ситуации, в которой теряется обращение.
