Если звонок есть в журнале, а новой карточки в CRM нет, сначала проверьте, должна ли интеграция создавать её для этого события. Затем проследите один конкретный звонок: условия запуска → отправка → ответ получателя → результат в CRM. Массово отправлять звонки заново до этой проверки не стоит: карточки могут уже существовать.
Внешне одинаковая проблема возникает по разным причинам. Звонок не подошёл под фильтр. Сценарий ждёт суть разговора. Подключение потеряло доступ. Данные добавились в прежнюю сделку, которую менеджер не видит в выбранной воронке. Для каждого случая нужно своё действие.
Ниже — порядок проверки для маркетолога, руководителя продаж и специалиста, который поддерживает интеграцию. Для начала хватит доступа к журналу звонков и настройкам; разбор технического ответа можно передать администратору.
1. Зафиксируйте ожидаемый результат
Фраза «звонок должен попасть в CRM» слишком расплывчата. Запишите, что именно должно появиться: контакт, лид, сделка, примечание или запись о разговоре. Это разные объекты, и создание одного не означает создание остальных.
Рабочая формулировка выглядит так: «После завершения входящего звонка из кампании “Сайт” должна появиться сделка в воронке “Новые продажи”, либо звонок должен дополнить подходящую существующую сделку». Последняя часть зависит от согласованных правил вашей интеграции.
Проверьте аккаунт CRM и выбранное подключение. Если у компании несколько порталов или интеграций, одинаковое название воронки ещё не доказывает, что вы смотрите в правильном месте. Уточните также, какой маршрут обслуживает звонок: готовая интеграция, прежнее подключение или собственный обработчик вебхуков.
Обзор возможностей есть в статье об интеграции CallKeeper с amoCRM. При диагностике ориентируйтесь на действующие настройки конкретного подключения: они определяют ожидаемый результат.
2. Выберите один звонок и сверьте условия
Начните с одного понятного примера. Найдите звонок в CallKeeper и сохраните его ID, дату и время с часовым поясом, тип звонка, виджет или кампанию. Убедитесь, что это нужный разговор, а не соседняя попытка дозвона.
Затем проверьте условия интеграции:
- Была ли она включена в момент события?
- Выбран ли нужный источник: звонок, заявка или разговор голосового агента?
- Проходит ли событие по типу звонка, виджету и кампании?
- Запускается ли действие после звонка или после появления другого материала?
- Разрешено ли создание новой сделки, либо интеграция только дополняет существующие?
В готовой интеграции amoCRM в CallKeeper есть режимы «Создавать сделки» и «Только дополнять существующие». Во втором случае отсутствие новой карточки само по себе нормально: нужно искать добавленный материал в открытой сделке клиента. Если подходящей сделки нет, режим дополнения не превращается автоматически в режим создания.
Скриншот интерфейса CallKeeper. Данные демонстрационные: показан выбор действия, от которого зависит появление новой сделки.
Для звонков также предусмотрен вариант «Когда готова суть разговора». Здесь завершение разговора и появление нужного для CRM события — разные моменты. Проверьте, готова ли суть, прежде чем искать сбой отправки. Эти настройки относятся к готовой интеграции; у прежнего подключения или собственного обработчика правила могут отличаться.
3. Найдите последний подтверждённый этап
Вместо вопроса «кто потерял заявку?» составьте короткую цепочку доказательств. На каждом этапе нужен свой результат.
- Звонок зафиксирован. Есть конкретная запись с ID и временем.
- Условия выполнены. Событие соответствует источнику, фильтрам и режиму интеграции.
- Действие запущено. Есть запуск сценария или запись отправки, относящиеся к этому обращению.
- Получатель ответил. Сохранены статус и содержимое ответа именно нужного запроса.
- Результат найден. Известен ID созданного или обновлённого объекта, и в нём есть ожидаемые данные.
Журнал готовых интеграций и журнал отправок вебхуков отвечают на разные вопросы. Первый помогает понять, какой шаг сценария выполнялся. Второй показывает сохранённые сведения об отправке и HTTP-ответе. Наличие записи во втором журнале не означает, что вы проверили весь путь до CRM.
Если записи не нашли, сначала проверьте аккаунт, период, часовой пояс и фильтры. Отсутствие строки в выбранной выдаче ещё не доказывает, что запрос не отправлялся. В старых журналах часть данных может быть неполной; не пытайтесь восстановить по ним то, что не было сохранено.
4. Прочитайте смысл статуса
В журнале готовых интеграций CallKeeper полезно различать несколько ситуаций.
«Пропущено». Событие не прошло условия или сценарий завершился без действия по своему правилу. Откройте шаг и посмотрите причину. Например, для дополнения не нашлась открытая сделка. Повтор без изменения причины ничего не исправляет.
«Нужно решение». Есть неоднозначность — например, несколько подходящих контактов или сделок. Сначала разберитесь, какой объект нужен. Не удаляйте и не объединяйте карточки только ради запуска интеграции: в них может быть самостоятельная история работы.
Скриншот интерфейса CallKeeper на демонстрационных данных. Здесь нужно разобраться с выбором контакта или сделки; повтор сам по себе неоднозначность не устранит.
«Нет доступа». Проверьте состояние подключения и права в CRM. Восстановление доступа поручите тому, кто управляет интеграцией. Пароль и токены не нужны в обычном сообщении о проблеме.
«Нужна проверка». Результат внешнего действия неизвестен. Это особенно важно: запрос мог выполниться, хотя подтверждение не сохранилось или не дошло. Сначала сверяют CRM, затем принимают решение о повторе.
«Ошибка». Смотрите конкретный шаг и пояснение. Ошибка поиска контакта, отказ создать сделку и отказ добавить примечание — разные проблемы. Успешное создание сделки не отменяется автоматически оттого, что следующий шаг завершился ошибкой.
Если запуск ещё выполняется или ожидает материал, зафиксируйте состояние и время проверки. Не объявляйте его потерянным только потому, что карточки пока нет. Но и бесконечное ожидание без выяснения причины не заменяет диагностику.
5. Не останавливайтесь на зелёном HTTP-коде
Успешный ответ нужно читать вместе с адресом, методом и назначением запроса. Ответ вашего промежуточного сервера подтверждает его собственную операцию; он не является ответом CRM на создание сделки.
Показательный пример — HTTP 202: по стандарту HTTP запрос принят для обработки, но обработка ещё не завершена. Поэтому такой ответ нельзя превращать в утверждение «карточка создана».
У конкретного метода CRM может быть более точный контракт. Например, добавление сделок через API amoCRM возвращает HTTP 200 и данные созданных сделок с их ID. Это содержательное подтверждение именно операции создания. Сохраните полученный ID и проверьте соответствующий объект, а не только общее число сделок на экране.
Практический вопрос специалисту: «Какой именно запрос выполнился, что вернул получатель и по какому идентификатору найти результат?» Он полезнее, чем скриншот одной зелёной строки без контекста.
6. Проверьте CRM без лишних фильтров
Если в ответе есть ID объекта, начните с него. Если ID нет, ищите контакт по полному номеру клиента и просматривайте связанные сделки и историю изменений. Проверьте воронку, этап, ответственного, ограничения по дате и права текущего сотрудника.
Отдельно проверьте, не было ли обновления старой карточки. Фильтр «создано сегодня» не покажет вчерашнюю сделку, в которую сегодня добавили звонок. Новое примечание и новая сделка — разные результаты.
В amoCRM доступ к данным сделки через API зависит от прав пользователя, что отдельно указано в документации метода. Поэтому ситуацию «у администратора находится, у менеджера нет» сначала проверяют как вопрос видимости, а не повторной передачи.
Условный пример: звонок завершился в 11:40, интеграция настроена только на дополнение существующих сделок. В CRM уже есть открытая сделка от вчерашнего дня. Материал добавился туда, но менеджер смотрит только сегодняшние новые сделки. В этом случае передача сработала; исправлять нужно поиск и ожидания, а не отправлять звонок ещё раз.
7. Соберите короткий пакет для поддержки
Один полный пример позволяет проследить цепочку. Сообщение «за неделю пропало много звонков» сначала потребует уточнений. Подготовьте:
- аккаунт CallKeeper и название интеграции;
- ID звонка, дату, время и часовой пояс;
- тип звонка и его виджет или кампанию;
- ожидаемый объект CRM, воронку и правило создания или дополнения;
- ID запуска либо отправки, последний подтверждённый шаг, статус и текст ошибки;
- ID найденного контакта или сделки, если они есть;
- что уже проверили и были ли ручные повторы.
Дополните один проблемный пример одним успешным из того же маршрута, если такой есть. Сравнение поможет увидеть разницу в источнике, фильтрах или моменте появления материалов.
Вот шаблон, который можно заполнить:
Звонок [ID], [дата и время, часовой пояс], [кампания/виджет]. Интеграция [название], CRM [аккаунт]. Ожидали [создание сделки / дополнение объекта]. В журнале [ID запуска, шаг, статус]. В CRM проверили [объект, воронку, фильтры]; результат [что найдено]. Повторную отправку [не делали / когда и как делали]. Похожий успешный пример: [ID].
Для первичного обращения обычно достаточно идентификаторов и контекста. Если поддержке потребуется полный телефон, передайте его через согласованный закрытый канал. Не прикладывайте токены, заголовки авторизации или полную ссылку вебхука с секретом. Перед отправкой снимка экрана закройте сведения других клиентов.
8. Повторите действие только после сверки
Если результат неизвестен, сначала выясните, не создан ли объект. Повторная отправка всего обращения может создать дубль или повторное примечание. Даже ошибка одной попытки не исключает успешную следующую попытку.
После устранения причины проверьте одно обращение по согласованному сценарию. Подтвердите нужный объект CRM, связь с контактом, ожидаемый материал и отсутствие дубля. Затем отдельно определите, какие старые события действительно требуют восстановления: новые звонки могут уже проходить, а прежние — оставаться необработанными.
Рабочий итог проверки — не «интеграция зелёная», а конкретная связь: этот звонок привёл к этому объекту CRM и нужному действию. С таким результатом можно объяснить ситуацию менеджеру, исправить правило и проверить, что следующая заявка обработана правильно.