Интеграция Asterisk с Bitrix24 полезна не тогда, когда звонок просто появился в истории. Она должна убрать лишние действия менеджера: найти клиента, открыть карточку, зафиксировать результат и не потерять пропущенный. Если после подключения сотрудник всё равно работает в двух окнах и вручную создаёт активности, интеграция сделана наполовину.
- Определить события звонка, которые нужны CRM
- Не путать запись разговора и сам факт звонка
- Проверить очереди, пропущенные и callback до запуска
Как выглядит нормальный сценарий входящего звонка
АТС сообщает о входящем вызове, CRM ищет клиента по номеру и показывает карточку. Если контакт неизвестен, создаётся сценарий для нового обращения. После завершения вызова в CRM фиксируются статус, длительность, ответственный и ссылка на запись — если запись включена и её хранение допустимо по внутренним правилам компании.
Главное — заранее решить, какая сущность открывается сотруднику: контакт, лид, сделка или специальная форма оператора.
Что обычно требуется от интеграции
| Функция | Что получает сотрудник |
|---|---|
| Входящий call popup | Карточка клиента открывается в момент звонка |
| Click-to-call | Звонок запускается из CRM без ручного набора |
| История вызовов | Входящие и исходящие связаны с клиентом |
| Записи разговоров | Запись доступна из CRM по настроенным правам |
| Пропущенные | Можно поставить callback и контролировать возвратный звонок |
| Очереди | Видно, кто принял вызов и как он маршрутизировался |
Asterisk: готовый коннектор или собственная связка
Asterisk гибкий, поэтому вариантов подключения много. Если готовое приложение поддерживает вашу версию АТС и нужные сценарии, начинать разумнее с него. Собственный middleware имеет смысл, когда нужны особые очереди, нестандартная маршрутизация, интеграция нескольких АТС или собственная логика привязки звонка к CRM.
В кастомном варианте обычно используются события Asterisk и методы телефонии/REST Bitrix24. Здесь особенно важна обработка повторов: одно и то же событие не должно создавать несколько активностей.
Почему пропущенный звонок сложнее, чем кажется
Один клиент может дозвониться в очередь, уйти до ответа, перезвонить через минуту и поговорить с другим менеджером. Если система считает каждое событие отдельным «пропущенным», руководитель увидит ложную картину. Нужна логика закрытия пропущенного после успешного контакта и понятный период, в котором события связываются.
Отчёт «сколько пропущено» бесполезен без ответа на второй вопрос: сколько из них команда реально вернула клиенту.
Записи разговоров и доступ
Запись должна быть доступна только тем, кому она нужна по роли. Отдельно определите срок хранения, кто может скачивать файлы и что происходит после увольнения сотрудника. Техническая возможность записывать разговор не заменяет внутренний регламент и правовые основания.
Что тестировать перед запуском
Телефония кажется простой до первого редкого сценария. Поэтому набор тестов важнее красивого demo-звонка на презентации.
- известный клиент звонит с основного номера
- новый номер без контакта в CRM
- переадресация между двумя сотрудниками
- пропущенный в очереди и последующий callback
- исходящий click-to-call
- повторное событие от АТС
- недоступность Bitrix24 или middleware на несколько минут
Перед тем как закрыть задачу
- ✓Понятно, что открывать при входящем звонке
- ✓Настроена связь активности с CRM
- ✓Есть правила по записям разговоров
- ✓Пропущенные закрываются после callback
- ✓Отчёт проверен на реальных очередях
Хорошая связка Asterisk и Bitrix24 делает звонок частью CRM-процесса, а не отдельным техническим событием. Проектируйте не «интеграцию АТС», а путь оператора: кто звонит, что он видит, что фиксируется после разговора и как руководитель понимает, что ни один вызов не потерялся.
