Сделайте тестовый звонок на номер салона, оставьте его без ответа и найдите одно и то же обращение в журнале облачной АТС и в CRM. Сверьте номер, время и статус, затем проверьте, видит ли администратор задачу по этому обращению. Так вы проверите всю цепочку: от входящего вызова до работы сотрудника. Ниже — порядок проверки, который поможет отделить ошибку интеграции от настройки телефонии и подготовить понятный запрос в поддержку без доступа к программному коду.
Что подготовить перед тестовым звонком?
Откройте журнал вызовов в личном кабинете облачной АТС и раздел звонков в CRM. Понадобится доступ к обоим интерфейсам: по одной карточке клиента нельзя определить, где остановилась передача события. Если настройками занимается подрядчик, заранее попросите его быть на связи во время проверки.
Уточните, что именно передаёт ваша интеграция. Входящий, исходящий, пропущенный и переадресованный звонки — отдельные события. Наличие одного из них ещё не подтверждает передачу остальных. Такой принцип описан в материале об интеграции телефонии с amoCRM (TuneCRM).
- Выберите номер салона, на котором будете проверять входящие вызовы.
- Подготовьте мобильный телефон с номером, который отображается при звонке.
- Уточните, кто из сотрудников должен получать пропущенные обращения.
- Узнайте, где CRM показывает звонки: в карточке клиента, общем журнале или отдельном отчёте.
- Проверьте, включена ли передача пропущенных событий в настройках интеграции.
Если салон использует DIKIDI, порядок подключения можно сверить с описанием в статье на dkd.by. Названия разделов и доступные функции уточните для своего подключения: инструкция помогает найти нужные настройки, но результат подтверждает только тест.
Как провести проверку от звонка до задачи в CRM?
Проводите тест в согласованное с администратором время. Сотрудники должны знать, какой вызов оставить без ответа, чтобы проверка не затронула обращение настоящего клиента. Не меняйте рабочую маршрутизацию ради первого теста.
- Позвоните с подготовленного телефона на номер салона и завершите вызов после того, как сработает обычный сценарий без ответа.
- Найдите этот вызов в журнале облачной АТС по номеру и времени.
- Найдите соответствующее событие в CRM через общий журнал звонков.
- Сверьте номер, время и итоговый статус в обеих системах.
- Откройте CRM под учётной записью администратора и проверьте доступность обращения для работы.
Зафиксируйте результат каждого шага. Записи «в АТС вызов есть, в общем журнале CRM отсутствует» уже достаточно, чтобы сузить поиск причины. Формулировка «телефония не работает» не показывает, на каком участке возникла ошибка.
Отдельно проверьте звонок от клиента, который уже есть в базе, и обращение с нового номера. В первом случае посмотрите, к той ли карточке CRM привязала событие. Во втором выясните, где система оставила обращение: она может показать его в общем журнале без автоматического создания клиента. Ожидаемое поведение нужно сверить с возможностями конкретной интеграции.
После успешного базового теста повторите проверку для перевода между сотрудниками, если салон использует такой сценарий. Первый администратор может не ответить, а следующий — принять вызов. Проверьте, как АТС обозначила итог разговора и какой статус получила CRM. Отдельный неотвеченный участок вызова не стоит автоматически считать потерянным обращением.
Где искать причину, если звонок не появился в CRM?
Начните с последнего места, где событие точно видно. Если вызова нет даже в журнале АТС, проверяйте номер и маршрут входящего звонка вместе с провайдером телефонии. Изменение API-ключа CRM на этом этапе не поможет найти причину.
Если АТС зарегистрировала пропущенный вызов, а CRM его не показывает, проверьте передачу событий. В зависимости от подключения обмен идёт через готовый модуль или вебхуки. Вебхук — это уведомление, которое одна система отправляет другой при событии, например после завершения звонка.
Попросите специалиста проверить, отправила ли АТС уведомление и приняла ли его CRM. Ошибка авторизации требует проверки ключа доступа, а отсутствие отправки — проверки подписки на нужное событие. Порядок такой диагностики подробнее разобран в материале о настройке интеграции облачной АТС и CRM через вебхуки.
Если провайдер требует разрешить подключения с определённых IP-адресов, возьмите актуальный список у поставщика интеграции. Не копируйте адреса из чужой инструкции и не отключайте сетевой экран целиком. Поддержке нужны время теста, номер линии и описание ошибки; секретный ключ в обычную переписку не отправляйте.
Бывает, что событие уже находится в CRM, но администратор его не видит. Тогда проверьте фильтр периода, ответственного сотрудника и права доступа. Поиск по номеру в общем журнале помогает отличить отсутствие события от ошибки отображения в конкретной карточке.
Если вместе с пропущенными событиями сотрудники замечают обрывы разговоров или недоступность рабочих телефонов, отдельно проверьте интернет для облачной АТС. Проблемы офисного подключения и сбой обмена между облачными сервисами требуют разных проверок. Для задачи подрядчику разделите их: связь на рабочем месте, маршрутизация в АТС и доставка события в CRM.
Какие типичные ошибки искажают результат?
Даже успешная передача тестового звонка не подтверждает работу всех сценариев салона. Проверяйте именно тот маршрут, по которому звонят клиенты: общий номер, распределение между администраторами и завершение вызова без ответа.
- Проверяют только принятый звонок. Исправление: отдельно оставьте вызов без ответа и найдите его итоговый статус в обеих системах.
- Ищут событие только в карточке клиента. Исправление: начните с общего журнала CRM, затем проверьте привязку к карточке.
- Принимают недозвон до одного сотрудника за потерю всего обращения. Исправление: посмотрите полную цепочку вызова и её завершение.
- Считают уведомление завершённой настройкой. Исправление: проверьте, кто видит обращение и где фиксирует результат работы с ним.
- Одновременно меняют ключ доступа, маршрут и фильтры. Исправление: меняйте одну настройку и повторяйте тот же тест.
После исправления повторите исходный сценарий с того же телефона. Сравнение будет понятнее, если менялась только одна настройка. Сохраните время повторного теста рядом с первым результатом, чтобы поддержка могла найти оба события.
Как понять, что проверка завершена?
Техническая часть работает, когда один тестовый вызов можно проследить от журнала АТС до нужного раздела CRM, а номер и итоговый статус совпадают. Проверьте это под учётной записью администратора: доступ руководителя или настройщика ещё не означает, что сотрудник увидит обращение на смене.
Для рабочего процесса нужен следующий уровень проверки. У пропущенного обращения должен быть ответственный, а результат контакта с клиентом должен оставаться в CRM. Само уведомление не показывает, взял ли сотрудник обращение в работу. Разделение уведомления, ответственности и контроля результата описано в материале об обработке пропущенных звонков для малого бизнеса Беларуси (smart-call.by).
Сохраните короткий протокол: какой номер проверили, когда прошёл тест, где появилось событие и кто получил доступ к нему. Он пригодится после замены провайдера телефонии, изменения маршрута или обновления интеграции. В задачу на подключение облачной АТС включите такой протокол как результат приёмки, наряду с проверкой связи на рабочих местах.
Сейчас откройте журнал АТС и запишите номер и время одного пропущенного вызова для сверки с CRM — это займёт меньше двух минут.
