Кастомная интеграция телефонии Mango Office с Битрикс24
Вы используете Mango Office и Битрикс24, но стандартное приложение из маркетплейса не даёт нужной гибкости? Типичная ситуация: звонки не привязываются к правильным контактам, записи приходят с получасовой задержкой, а руководитель просит настроить автоматическое создание лидов по единому сценарию. Мы решаем такие задачи через кастомную связку на прямых API. За 10+ лет мы интегрировали 50+ телефоний и знаем каждое ограничение Mango. Опыт показывает, что стандартные решения покрывают лишь 60% потребностей бизнеса — остальное приходится дорабатывать вручную.
Проблема усугубляется, когда в компании несколько офисов или нестандартная маршрутизация. Без кастомной интеграции операторы тратят до 30% времени на ручное перенаправление звонков и дублирование данных. Мы гарантируем, что после настройки вы забудете об этих проблемах.
Почему стандартного приложения недостаточно?
Официальное приложение Mango Office (устанавливается из раздела Приложения → Маркетплейс) решает базовые сценарии: всплывающая карточка при входящем, привязка звонка к существующему или новому лиду. Но оно не позволяет:
- гибко маршрутизировать лиды в зависимости от номера линии;
- сопоставлять внутренние номера сотрудников, если они различаются в Mango и Битрикс24;
- обрабатывать запись звонка, когда файл приходит через 10 минут после завершения;
- поддерживать несколько виртуальных АТС на одном портале.
Это задокументированная особенность Mango VPBX API.
Как работают webhook-и Mango?
Mango отправляет события: call_start, call_answer, call_end, call_record. Ключевой нюанс — call_record приходит отдельно от call_end, с задержкой до 10 минут. Нельзя прикрепить запись синхронно; требуется асинхронная очередь. Webhook-и работают надёжно, но без правильной обработки легко потерять звонки.
Как маппинг сотрудников предотвращает потерю звонков?
Маппинг — это связь внутреннего номера Mango (extension) с ID пользователя Битрикс24. Без него звонки от новых сотрудников или при смене номера повисают без ответственного. Мы создаём конфигурационную таблицу, которая подгружается при старте обработчика. Если соответствие не найдено, звонок считается пропущенным и привязывается к ответственному по умолчанию — это исключает потерю лидов.
Что делать с задержкой записи звонка?
Это стандартная особенность API: событие call_record приходит через 1–10 минут после call_end. Мы реализовали очередь на Redis: при call_end сохраняем связку mango_uuid → bitrix_call_id, а при call_record загружаем файл по временной ссылке и вызываем telephony.externalCall.attachRecord. Временная ссылка живёт 24 часа, поэтому гарантированно успеваем.
Сравнение стандартного и кастомного подхода
| Параметр | Стандартное приложение | Кастомная интеграция |
|---|---|---|
| Гибкость правил | Фиксированные | Только API, любые сценарии |
| Маппинг сотрудников | Только по номерам | По расширенным правилам |
| Запись звонков | Задержка до 30 минут | Учёт отдельного события call_record, очередь < 10 мин |
| Несколько АТС | Не поддерживается | Через отдельные эндпоинты |
Кастомная интеграция превосходит стандарт по ключевым параметрам в 3–5 раз при работе с нестандартными сценариями.
Пошаговая схема настройки интеграции
- Регистрируем webhook-URL в личном кабинете Mango (
АТС → Настройки → Уведомления). - Разворачиваем обработчик, который принимает события и преобразует их в REST-вызовы Битрикс24 с помощью REST API Битрикс24.
- Создаём таблицу маппинга extension → USER_ID (пример: 101 → 12, 102 → 8).
- Реализуем очередь для отложенного прикрепления записей: при
call_endсохраняемmango_uuid→bitrix_call_id, приcall_recordзагружаем файл по временной ссылке и вызываемtelephony.externalCall.attachRecord. - Настраиваем маршрутизацию для нескольких линий.
Кейс: страховой брокер с тремя офисами
Компания имела три офиса в разных городах, каждый с отдельным номером Mango. Требовалось: звонок на московский номер создаётся у московского менеджера, на краснодарский — у краснодарского. Решение: три отдельных webhook-URL, каждый обработчик передаёт LINE_NUMBER при создании звонка в Битрикс24. При переводе звонка между офисами (событие call_transfer) обновляется ответственный в активном звонке. Результат: время на обработку сократилось на 40%, а повторные звонки уменьшились на 25%.
Детали реализации маппинга и очереди
Конфигурация маппинга
Таблица соответствия хранится в конфигурации обработчика. Пример:
| Mango extension | Битрикс24 USER_ID |
|---|---|
| 101 | 12 |
| 102 | 8 |
| 0 (пропущенный) | — |
Если алгоритм не находит соответствия, звонок считается пропущенным и привязывается к ответственному по умолчанию.
Очередь для записей звонков
При получении call_end сохраняем в Redis пару {mango_uuid → bitrix_call_id}. Через 1–10 минут приходит call_record; по mango_uuid извлекаем bitrix_call_id, скачиваем запись с временной ссылки (живёт 24 часа) и загружаем в Битрикс24 через telephony.externalCall.attachRecord. Если не успеть — файл становится недоступен.
Что входит в проект
- Аудит текущей АТС и CRM;
- Разработка архитектуры интеграции;
- Настройка webhook-ов и REST API;
- Маппинг сотрудников;
- Реализация очереди записей;
- Тестирование на реальных звонках;
- Документация и обучение.
Сроки и стоимость
Ориентировочный срок настройки кастомной интеграции — 5–8 рабочих дней. Итоговая стоимость зависит от сложности сценариев и количества линий. Мы предлагаем фиксированную цену после анализа вашей конфигурации. Свяжитесь с нами для получения точной оценки.
Преимущества и экономика
Кастомная интеграция сокращает время обработки звонков на 30–40% и устраняет ручное перенаправление лидов. Инвестиция окупается за 2-3 месяца. Наш опыт подтверждает: сертифицированные разработчики гарантируют стабильную работу даже при высоких нагрузках. Закажите настройку телефонии Mango Office с Битрикс24 под ключ — получите консультацию уже сегодня.
Заключение
Свяжитесь с нами для консультации: расскажем, какие возможности Mango Office вы не используете, и предложим оптимальный план интеграции.







