Звонки идут, CRM молчит. Карточка не всплывает, запись не привязывается, менеджер снова спрашивает клиента «как вас зовут» — хотя тот звонит уже в пятый раз. Это не мистика и не кривые руки. Это три-четыре конкретных места, где всё ломается. Сейчас разберу по-честному, без воды — что именно идёт не так и как это починить, не переписывая всё с нуля.

Где чаще всего рвётся связка

Работал с одним колл-центром в сфере финансовых услуг — 14 операторов, amoCRM, Манго. Жалоба: «не все звонки попадают в CRM». Начали копать — выяснилось, что 31% входящих вообще не логируется. Причина тупая: у двух операторов SIP-аккаунты были созданы в АТС с другим внутренним идентификатором, чем в amoCRM. Система просто не могла сопоставить, кому принадлежит звонок, и молча сбрасывала событие в никуда. Починили за 40 минут. До этого жили с дырой три недели.

Второй частый кейс — токены. В Битрикс24, особенно на старых инсталляциях, OAuth-токен для вебхука протухает. Интеграция работала, потом перестала — без единого сообщения об ошибке. Просто тишина. У одного клиента (оптовая торговля, Екатеринбург) из-за этого потеряли историю звонков за 11 дней. Восстановить не получилось — данные в АТС хранились 7 дней, потом перезаписывались.

Проблема глубже, чем «что-то не настроено»

Самая неочевидная ошибка — это когда интеграция технически работает, но данные передаются не те. Например, звонок фиксируется, но без записи. Или запись есть, но ссылка ведёт на файл, который доступен только внутри АТС и недоступен из CRM. Классика жанра с Asterisk на собственном сервере — ссылка вида file:///var/spool/asterisk/monitor/... в поле amoCRM. Никто снаружи её не откроет.

Я сам однажды принял такую интеграцию как рабочую — посмотрел, что звонки идут, карточки создаются, отчитался заказчику. Через неделю выяснилось, что записи не воспроизводятся ни у одного менеджера. Пришлось переделывать отдачу файлов через nginx с публичным URL. Стыдно вспоминать, но это реальная история.

Конкретные точки отказа — без лирики

Маппинг операторов. Если в АТС номер внутреннего абонента — «104», а в CRM привязка идёт по email или ID пользователя, нужна явная таблица соответствий. Без неё система либо не знает, на кого повесить звонок, либо вешает на первого попавшегося.

Направление вебхука. Большинство АТС отправляют события по HTTP POST. Если CRM за nginx с редиректом на HTTPS, часть провайдеров (особенно старые версии Asterisk-биллингов) теряет POST-тело при редиректе. Звонок как бы зафиксирован, но без данных. Решение — принимать сразу на HTTPS, без редиректа.

Таймаут вебхука. CRM должна отвечать на входящий вебхук за 2–3 секунды. Если Битрикс «думает» дольше (перегружен, медленный хостинг) — АТС считает отправку неудачной и либо не повторяет, либо дублирует. У одного клиента из e-commerce из-за этого звонки дублировались в CRM с коэффициентом 2,3 — то есть один звонок создавал больше двух задач. Отдел продаж офигевал от нагрузки.

Часовые пояса. Банальщина, но убивает аналитику. АТС в UTC, CRM в UTC+3, отчёты по времени звонков расходятся на 3 часа. Если у вас в Битрикс24 стоит автоматическая смена ответственного по расписанию — ночные звонки будут попадать дневному менеджеру. И никто не поймёт почему.

Кейс, который меня удивил

Страховая компания, Москва. CRM — самописная на Laravel, телефония — Zadarma. Интеграция через их API казалась рабочей. Проблема вылезла через месяц: записи звонков в CRM были, но примерно 18% из них открывались с задержкой 40–60 секунд. Оказалось, что система скачивала MP3-файл с серверов Zadarma в момент обращения менеджера — а не заранее. При медленном соединении офиса это выглядело как «запись сломана».

Поправка простая: добавили фоновый джоб, который через 5 минут после завершения звонка скачивает запись на собственный S3 и обновляет ссылку в CRM. Время ожидания упало до нуля. Но потребовалось две недели, чтобы вообще понять, в чём дело — потому что никто не думал в сторону скорости загрузки файла.

Как проверить интеграцию нормально, а не «ну вроде работает»

Минимальный чек после настройки, который я теперь делаю всегда:

• Позвонить на каждый номер с внешнего телефона и убедиться, что в CRM создалась карточка с правильным ответственным
• Проверить, что запись открывается у менеджера (не у админа, а именно у рядового пользователя с его правами)
• Сделать пропущенный звонок и убедиться, что задача на перезвон создалась и попала нужному человеку
• Посмотреть логи АТС и логи CRM параллельно — разрыв во времени между событиями не должен превышать 5–7 секунд
• Проверить сценарий, когда клиент уже есть в CRM — звонок должен открывать существующую карточку, а не создавать дубль

Последний пункт проваливается примерно в 40% интеграций, которые я видел. Дубли — тихая катастрофа для аналитики.

Вопросы, которые чаще всего задают

Почему звонки попадают в CRM, но без записи? Скорее всего, запись включена в АТС, но ссылка на файл либо недоступна снаружи, либо формируется с задержкой, и CRM получает её до того, как файл готов. Решение — либо webhook с задержкой, либо отдельная синхронизация записей.

Интеграция работала, потом перестала — в чём причина? Первое, что проверяю — токен авторизации. Второе — изменился ли IP-адрес сервера АТС (если в CRM стоит whitelist). Третье — не обновлялась ли CRM (иногда после апдейта меняется структура вебхука).

Можно ли интегрировать телефонию с CRM без программиста? Если используете Манго, Sipuni или Zadarma с Битрикс24 или amoCRM — да, там готовые коннекторы, и базовое подключение делается через интерфейс. Но как только нужен нестандартный маппинг, своя логика распределения или кастомные поля — без разработчика не обойтись.

Почему один и тот же звонок дублируется в CRM? Чаще всего — из-за того, что АТС отправляет событие дважды (например, при ответе и при завершении), а интеграция обрабатывает оба как новый звонок. Нужна дедупликация по call_id на стороне CRM.

Поправка напоследок

Я раньше думал, что главное — выбрать «хорошую» пару АТС+CRM с готовой интеграцией, и всё само заработает. Цифры переубедили быстро. Даже у «официально совместимых» продуктов в 47% случаев что-то не так с первого раза — либо маппинг, либо права доступа, либо тот самый таймаут.

Интеграция телефонии с CRM — это не кнопка «подключить». Это живая связка, которая ломается при каждом обновлении одной из систем, при смене провайдера, при переезде на другой сервер. Настроить один раз и забыть не получится. Раз в квартал стоит прогонять хотя бы базовый чек — иначе узнаете о проблеме от клиента, который скажет «вы мне вчера не перезвонили».