Мониторинг интеграций CRM: как заметить сбой передачи заявок

Контроль интеграции начинается с судьбы заявки

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

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

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

Ручная сверка: понятный старт с ограниченным охватом

При ручной сверке сотрудник выбирает обращения, которые принял сайт, и ищет соответствующие карточки в Битрикс24. Для этого нужен общий признак: номер заявки, идентификатор отправки или другая связь, которую предусмотрел разработчик. Имя клиента для поиска ненадёжно. Оно может повторяться, содержать опечатку или отличаться от названия карточки.

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

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

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

Технические сигналы объясняют причину остановки

Второй подход следит за ответами сервисов, доступом к ним и ошибками обмена. Он помогает заметить отклонение раньше ручного просмотра. В рабочем журнале ответ на запрос связывают с исходной заявкой и состоянием её обработки, чтобы специалист мог перейти от технического сигнала к затронутому обращению.

В облачном Битрикс24 действуют лимиты REST-запросов — обращений одной программы к другой: ограничиваются как частота отправки, так и суммарное время выполнения конкретного метода, то есть отдельной операции сервиса. Причины у ошибок разные. Документация платформы связывает QUERY_LIMIT_EXCEEDED с интенсивностью запросов, а OPERATION_TIME_LIMIT — с накопленным временем метода для приложения или вебхука. При второй ошибке остальные методы могут продолжать работу. Поэтому подрядчик сначала определяет причину остановки, затем выбирает порядок восстановления: бездумное увеличение числа попыток способно добавить нагрузку к уже возникшей проблеме.

У администратора есть штатная статистика REST. В ней можно отбирать данные по приложению, вебхуку, методу или событию и дате, а доступный период составляет максимум четырнадцать дней. Эти условия указаны в справке Битрикс24. График полезен для расследования скачка запросов. Он не является списком всех потерянных обращений, поэтому для восстановления потребуется журнал самой интеграции.

Что включать в сообщение об ошибке

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

Я рекомендую отдельные сообщения для остановки доступа, превышения лимитов и ошибки содержимого заявки. Общая надпись «Интеграция не работает» заставляет дежурного каждый раз начинать расследование с нуля, хотя исполнителю уже известен ответ сервиса. При этом пользователю уведомления нужна расшифровка: что затронуто и кто берёт работу.

Проверка результата замечает тихие пропуски

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

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

Контрольная заявка позволяет пройти путь от формы до CRM, когда исполнитель предусмотрел тестовые данные и получателей, по которым продавцы не начнут обычное общение, а подключённые сервисы не отправят сообщения посторонним людям. Пометка видна участникам проверки. Задание описывает, где появится такая запись и кто подтвердит её получение. После прохода тестовые сведения отделяют от рабочих. Частоту выбирают по допустимой задержке обнаружения и нагрузке: для формы, которую можно оставить без наблюдения до следующего рабочего дня, и для непрерывного потока обращений потребуется разный порядок контроля.

Тестовая отправка может пройти после короткого сбоя, пока старые обращения ещё остаются без карточек. Поэтому я бы использовал оба способа для критичной формы. Сопоставление показывает конкретные расхождения. Контрольный проход выясняет, способен ли путь работать сейчас, а вместе эти сведения помогают отделу различать уже устранённую техническую неисправность и обращения, которым ещё требуется внимание исполнителя.

У уведомления есть получатель и действие

В уведомлении стоит назвать направление обмена, начало проблемы, затронутую часть обращений и дать специалисту ссылку на закрытый журнал, чтобы он мог сразу перейти к поиску причины, а не собирать исходные сведения в переписке. Маркетолог получает описание влияния на работу, подрядчик — технические подробности по защищённому каналу; контакты клиентов остаются в предназначенной для них системе.

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

Нерабочее время и повторные тревоги

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

Повторные сообщения об одной причине лучше объединять. Когда каждый неудачный запрос создаёт новое уведомление, важный сигнал теряется в потоке одинаковых сообщений. Исполнителю можно поручить вести одну запись о сбое, обновлять в ней список затронутых обращений и отдельно сообщать о восстановлении. В журнале сохраняют историю разбора, а в рабочем канале называют ответственного и время следующего сообщения.

Зелёный индикатор — начало сверки после сбоя

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

Я советую сначала определить, как сопоставлять обращения, а затем запускать восстановление, чтобы исполнитель мог отличить уже обработанные записи от ещё не переданных и показать отделу продаж понятный итог по каждой из них. Начало работы — исходный список. Завершение — сведения о судьбе записей из него. Кто-то уже ответил клиенту через резервный канал, другое обращение ещё предстоит обработать, для третьего нужно уточнить недостающие данные. Эти различия определяют работу людей, тогда как устройство повторной доставки остаётся технической задачей разработчика.

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

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

Какой вопрос задать подрядчику первым

Название сервиса мониторинга само по себе не объясняет, что получит отдел при сбое. Первый вопрос подрядчику я бы сформулировал так: «Как мы узнаем, что заявка принята сайтом, но не появилась в рабочем списке менеджера?» Предметный ответ назовёт источник сведений, адресата сообщения и способ найти затронутые обращения.

После этого легче выбрать объём доработки: если связь между записями уже есть, можно обсуждать предупреждения и восстановление, а если её нет, исполнителю сначала потребуется организовать учёт принятой заявки и результата её передачи. Тогда можно обсуждать сроки обнаружения. У каждой записи появится основание считать её обработанной либо продолжить разбирательство. Для обсуждения интеграции с Битрикс24 достаточно подготовить адрес формы, направление в CRM, контакт нынешнего исполнителя и порядок работы отдела во время остановки. Эти сведения помогут выбрать способ контроля под ваш процесс.