Если разговор состоялся, но звонок не появился в CRM, проверьте три звена: данные Asterisk, результат обработки в коннекторе и ответ CRM. Сначала найдите конкретный вызов и причину расхождения, затем определите, какие действия действительно нужно повторить. Такой подход помогает восстановить историю общения и избежать лишних записей.

Менеджер обсудил с клиентом заказ, договорился отправить предложение и положил трубку. Позже коллега открывает карточку: сегодняшнего разговора там нет. Возникает спор — сотрудник не позвонил, выбрал другую карточку или интеграция не сохранила событие?

Эта ситуация встречается и в небольшом отделе продаж, и при большом потоке обращений. Разберём порядок проверки на примере Битрикс24 и Asterisk, а также решения, которые мы применяли в проекте Авито. Практические рекомендации ниже — порядок диагностики; они не означают, что у каждой компании причины ошибки одинаковы.

Что означает отсутствие звонка в CRM

Отсутствующий звонок в CRM — это обращение, которое не удалось найти в ожидаемой истории клиента, хотя в телефонной системе есть сведения о вызове. До проверки нельзя считать его окончательно потерянным: событие могло задержаться, оказаться в другой карточке или быть исключено правилами интеграции.

Важно различать событие звонка и аудиозапись. Если в карточке есть время разговора, сотрудник и результат, но запись не воспроизводится, регистрация уже произошла. В этом случае нужно проверять прикрепление и доступность файла, а не создавать звонок заново.

Ещё одна отдельная ситуация — пропущенный вызов, на который никто не ответил. Здесь речь прежде всего о полноте истории: разговор мог состояться, но CRM его не показывает. Отсутствие события мешает передать клиента коллеге, восстановить договорённости и оценить работу отдела.

Что показал опыт интеграции для Авито

В 2022 году Itgrix совместно с партнёром Эм Си Арт участвовал в переходе коммерческого подразделения Авито с Salesforce на Битрикс24. Партнёр отвечал за миграцию CRM, наша команда — за интеграцию Asterisk и особенности обработки звонков.

Подразделение совершало и принимало десятки тысяч звонков в день. Базовый этап занял полтора месяца, затем ещё полтора года продолжалась работа над стабильностью. По опубликованному кейсу, долю ошибок потоковой обработки удалось снизить с 3% до 0,1%.

Для оставшихся проблемных вызовов разработали специальные скрипты: они находили звонки, не обработанные успешно, запускали повторную обработку и формировали список для ручной проверки. Также настроили мониторинг коннектора с уведомлениями в корпоративный мессенджер. Эти результаты относятся к конкретному проекту и его инфраструктуре. Кейс интеграции Itgrix для Авито.

Для небольшого отдела продаж полезен тот же принцип: после отправки данных нужно убедиться, что ожидаемое действие в CRM выполнено. Иначе даже редкая ошибка остаётся незаметной до жалобы клиента или разбора сделки.

Почему звонок может не появиться в Битрикс24

Путь данных выглядит так: Asterisk фиксирует события, коннектор обрабатывает их, CRM принимает запрос и сохраняет результат. Проверять эту последовательность удобнее на одном конкретном примере.

CRM отклонила запрос

Битрикс24 ограничивает интенсивность REST-запросов. Например, QUERY_LIMIT_EXCEEDED означает превышение допустимой интенсивности, а OPERATION_TIME_LIMIT — ограничение по накопленному времени выполнения метода. Частые повторные запросы сами по себе проблему не решают: действия зависят от конкретного кода ошибки. Документация лимитов REST API Битрикс24.

Небольшое число менеджеров не исключает такую ситуацию. При диагностике полезно учитывать другие интеграции портала, но обвинять нагрузку без ответа API не стоит. Причина может быть в доступах или в данных отдельного вызова.

Сработали правила исключения

Отсутствие регистрации иногда соответствует настройкам. В документации Itgrix приведён пример: разговор переводят на сотрудника из чёрного списка, и звонок не регистрируется. Поэтому при проблемах после переводов нужно проверять участников и фильтры, а не только первый внутренний номер. Правила обработки и чёрные списки Itgrix.

Сравнивают разные единицы учёта

Один разговор не всегда равен одной строке телефонного журнала. Asterisk может создавать несколько CDR-записей для одного вызова; связать их помогает идентификатор linkedid. Поэтому разница между количеством строк АТС и событий CRM ещё не доказывает потерю звонков. Спецификация CDR Asterisk.

Как найти звонок и проверить восстановление

Шесть шагов для менеджера и администратора

1.       Соберите один точный пример. Запишите дату, время с часовым поясом, направление вызова, номер клиента и внутренний номер сотрудника. Отметьте перевод, очередь или обратный звонок, если они были.

2.       Проверьте CRM. Найдите обращение в детализации и связанных карточках. Попросите администратора проверить доступы и фильтры. Уточните, отсутствует само событие или только запись разговора.

3.       Найдите вызов в Asterisk. Администратор проверяет события разговора и его идентификатор. При переводах важна вся цепочка, а не случайная строка журнала.

4.       Проверьте результат коннектора. Выясните, получил ли он данные, разрешена ли регистрация и на каком действии остановилась обработка. Сохраните сообщение об ошибке и идентификатор созданного объекта CRM, если он есть.

5.       Устраните причину и согласуйте повторную обработку. Исправьте доступы, настройки или другой подтверждённый сбой. Затем используйте предусмотренный для установленной версии механизм восстановления, сначала для одного вызова.

6.       Проверьте результат в CRM. Убедитесь, что событие появилось у нужного клиента, сотрудник и время указаны корректно, а повторного лида или второго звонка не возникло. Если запись предусмотрена, отдельно проверьте её доступность.

Для обращения в поддержку можно приложить отчёт из раздела «Состояние системы» Itgrix. Этот способ указан в инструкции по установке и проверке интеграции. Вместе с отчётом передайте конкретный пример: формулировка «иногда пропадают звонки» оставляет слишком много вариантов для поиска.

Как Itgrix хранит результаты обработки

Начиная с Itgrix bx 3.13.0, состояние приложения хранится в базе SQLite state.db. В ней сохраняются результаты отдельных шагов, сведения о созданных объектах CRM и причины пропуска действий. Это позволяет разбирать частично обработанные вызовы и учитывать уже выполненные операции при повторной обработке.

Документация также описывает автоматическую переобработку ошибок по расписанию с приоритетом текущих звонков. Для неё нужны сохранённые данные и соблюдение условий запуска; обещать появление любого события через фиксированное время нельзя. Эти возможности описаны для коннектора Битрикс24: установленную версию и настройки следует проверить отдельно. База данных Itgrix.

Каких ошибок избежать при восстановлении

Не создавайте сразу новый лид для каждого отсутствующего события. Клиент уже может быть в CRM, а сбой мог произойти после создания части объектов. Массовый повтор без проверки состояния способен усложнить поиск дублей.

Не удаляйте базу состояния и диагностические данные перед разбором. Не запускайте сразу несколько массовых повторов: сначала проверьте один вызов и убедитесь, что причина устранена. Эти рекомендации особенно полезны, когда за АТС и CRM отвечают разные подрядчики.

Что контролировать небольшому отделу продаж

Начните с короткой регулярной сверки. За выбранный период сравнивайте завершённые внешние вызовы, которые по правилам должны попадать в CRM, с фактически зарегистрированными событиями. Исключения и переводы учитывайте одинаково в обеих системах.

Для контроля достаточно фиксировать число расхождений, возраст самого старого неразобранного вызова и результат повторной обработки. Отдельно назначьте человека, который получает уведомление и доводит проверку до конца. Частоту сверки выберите по объёму звонков и допустимой задержке.

Если звонок есть в Asterisk, но его нет в CRM, начните с одного конкретного примера: времени, номера клиента и сотрудника. Проверьте, не скрыто ли событие фильтром и не оказалось ли оно в другой карточке. Затем сопоставьте вызов в АТС с результатом обработки в коннекторе и ответом CRM. Сам факт разговора не подтверждает успешное сохранение события в клиентской базе. Причиной расхождения могут быть настройки исключений, ошибки доступа, ограничения запросов или неполные данные звонка. Повторную обработку выполняют после выяснения причины и проверки уже созданных объектов. Такой порядок снижает риск появления дублей. После восстановления нужно проверить привязку к клиенту, время, ответственного и доступность записи, если она предусмотрена. Для постоянного контроля полезно регулярно сверять вызовы, подлежащие регистрации, с событиями CRM и отдельно разбирать оставшиеся расхождения. Важен также возраст необработанных обращений: даже восстановленный через несколько дней звонок мог понадобиться менеджеру значительно раньше. Ответственный за проверку должен видеть такие задержки и причину каждой нерешённой ошибки.

Частые вопросы

Почему разговор состоялся, а звонка в CRM нет?

Телефонное соединение и регистрация в CRM — разные операции. Проверьте наличие события в других карточках, правила исключения, результат коннектора и ответ CRM. Причину определяют по конкретному вызову.

Поможет ли перезапуск коннектора?

Перезапуск может восстановить работу службы, но не исправляет все причины отсутствия события. Сначала сохраните сведения об ошибке и проверьте доступы, настройки и состояние обработки звонка.

Можно ли восстановить звонок за прошлую неделю?

Возможность зависит от сохранности событий АТС, данных коннектора и уже выполненных действий в CRM. Перед восстановлением нужно найти конкретный вызов и проверить доступный для вашей версии способ повторной обработки.

Повторная обработка создаст дубли?

Риск зависит от механизма повтора и сохранённых результатов предыдущих действий. В Itgrix bx начиная с 3.13.0 база состояния помогает учитывать выполненные шаги. Перед массовым восстановлением проверьте один проблемный вызов.

Что делать, если событие есть, но запись не открывается?

Проверьте прикрепление файла, адрес хранения и доступ к нему. Отсутствие аудио само по себе не требует повторной регистрации звонка или создания новой карточки клиента.

Проверьте полноту истории звонков вместе с Itgrix

История общения помогает отделу продаж продолжать работу с клиентом, даже когда меняется менеджер. Поэтому интеграции нужны понятная диагностика, контроль результата и возможность разобраться с отдельным вызовом.

Звонки есть в Asterisk, но история в Битрикс24 неполная? Напишите команде Itgrix. Укажите версию коннектора, время проблемного звонка и то, что отсутствует в CRM: событие, привязка к клиенту или аудиозапись. Поможем разобраться в вашей схеме интеграции и определить дальнейшие действия.

Возможности подключения описаны на странице интеграции Asterisk и Битрикс24.