Кастомна інтеграція Mango Office з Бітрікс24: налаштування телефонії

Кастомна інтеграція телефонії 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 години, тому гарантовано встигаємо.

Порівняння стандартного та кастомного підходу

Кастомна інтеграція перевершує стандарт за ключовими параметрами у 3–5 разів при роботі з нестандартними сценаріями.

Покрокова схема налаштування інтеграції

1. Реєструємо webhook-URL в особистому кабінеті Mango (АТС → Налаштування → Сповіщення).
2. Розгортаємо обробник, який приймає події та перетворює їх у REST-виклики Бітрікс24 за допомогою REST API Бітрікс24.
3. Створюємо таблицю маппінгу extension → USER_ID (приклад: 101 → 12, 102 → 8).
4. Реалізуємо чергу для відкладеного прикріплення записів: при call_end зберігаємо mango_uuid → bitrix_call_id, при call_record завантажуємо файл за тимчасовим посиланням і викликаємо telephony.externalCall.attachRecord.
5. Налаштовуємо маршрутизацію для декількох ліній.

Кейс: страховий брокер з трьома офісами

Компанія мала три офіси в різних містах, кожен з окремим номером Mango. Потрібно було: дзвінок на московський номер створюється у московського менеджера, на краснодарський — у краснодарського. Рішення: три окремих webhook-URL, кожен обробник передає LINE_NUMBER при створенні дзвінка в Бітрікс24. При переведенні дзвінка між офісами (подія call_transfer) оновлюється відповідальний в активному дзвінку. Результат: час на обробку скоротився на 40%, а повторні дзвінки зменшилися на 25%.

Деталі реалізації маппінгу та черги

Конфігурація маппінгу

Таблиця відповідності зберігається в конфігурації обробника. Приклад:

Якщо алгоритм не знаходить відповідності, дзвінок вважається пропущеним і прив'язується до відповідального за замовчуванням.

Черга для записів дзвінків

При отриманні 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 ви не використовуєте, та запропонуємо оптимальний план інтеграції.