Сайт и CRM настроены, форма благодарит за обращение, а менеджер неделями не видит часть заявок с сайта. Иногда о потере первым узнаёт клиент: перезванивает сам и слышит «мы вам перезвоним». После такого разговора исправлять нужно уже не интеграцию, а отношение к компании.
Позиция, с которой написана статья: «настроено» и «работает» — разные состояния. Заявка считается обработанной не тогда, когда форма показала подтверждение, а тогда, когда в CRM появилась запись и на неё отреагировал человек. Между этими двумя точками — цепочка, которая умеет ломаться молча.
Ниже — как именно теряются заявки с сайта без единой «ошибки», почему поломку замечают с опозданием в дни и недели и какой минимальный контроль сокращает это время до минут. ИИ здесь ни при чём: это вопрос правил и проверок.
Как заявка теряется без единой ошибки
Типовая передача выглядит так: клиент заполняет форму, сайт отправляет данные в CRM через вебхук или API-запрос, CRM создаёт лид, дальше работает робот или менеджер. Каждый шаг отвечает статусом «успех». Именно это успокаивает.
Проблема в том, что «успех» в этой цепочке не означает «дошло». Выделяются три режима тихой потери.
Ответ изменился, статус остался успешным. Внешний API может в один день начать возвращать сумму строкой вместо числа, объект — внутри массива, полное имя — двумя отдельными полями. Запрос по-прежнему проходит с кодом 200, а расчёты и сопоставление полей ниже по цепочке уже ломаются без какого-либо сигнала [1].
Лимит сработал — никто не посмотрел. В облачном Битрикс24 интенсивность REST-запросов ограничена «дырявым ведром»: когда счётчик превышает порог, API отвечает статусом 503 с кодом QUERY_LIMIT_EXCEEDED, а на большинстве тарифов устойчивый предел — 2 запроса в секунду [4]. Если отправитель не проверил ответ, форма показала клиенту «спасибо», а заявка в CRM не создалась. Ни одна строка кода не сломалась — просто в этот момент CRM была занята другой автоматизацией.
Приёмник молчал, отправитель сдался. У поставщиков вебхуков успехом считается код 2xx в течение примерно 15 секунд. Неудачные доставки повторяются по расписанию с нарастающими паузами — минуты, часы — а после исчерпания попыток сообщение помечается как несостоявшееся [3]. Если ваш приёмный адрес лежал дольше, события «ушли» и осели в чужом журнале. Формально отправитель сделал всё правильно.
Во всех трёх случаях техника считает, что свою работу сделала. Незакрытой остаётся одна позиция: заявка не дошла до человека, который должен был её обработать.
Почему поломку замечают через неделю, а не через минуту
Три причины складываются в одну и ту же картину.
Проверка живёт в момент запуска. Интеграцию тестируют один раз — при сдаче подрядчиком. Изменение ответа API может произойти через недели после этого, и тесты его не увидят, потому что их больше не запускают [1].
Проверяют форму, а не CRM. Контрольная заявка — простейший способ поймать любую из трёх поломок, включая изменившееся поле: тестовая заявка не доедет точно так же, как боевая. Но при приёмке смотрят на «спасибо» на экране, а не на запись в CRM — а форма говорит «спасибо» во всех трёх режимах молчаливой потери.
Журнал есть — читателя нет. Ошибки честно пишутся в журнал исполнений. Но журнал сам по себе проблему не создаёт: он молчит, пока его не открыли. В малом бизнесе его обычно открывают после первой жалобы клиента.
Пока контроля нет, время обнаружения сбоя определяет самый далёкий от техники участник процесса — клиент.
Минимальный контроль, который ловит сбой
Система мониторинга корпоративного уровня не нужна. Нужны четыре правила, которые помещаются в одну страницу регламента.
1. Заявка считается доставленной, когда она в CRM. Критерий результата — созданная запись и реакция владельца процесса, а не сообщение «спасибо» на форме. Это определение стоит зафиксировать письменно: споры о том, «работает ли интеграция», чаще всего упираются в разное понимание слова «работает».
2. Ответ внешней системы проверяется на каждом запуске. Передача должна валидировать ответ до того, как двигаться дальше: обязательные поля, типы данных, код ошибки. Нарушение — это принудительная ошибка исполнения, а не тихое продолжение. В n8n для этого есть отдельный узел Stop And Error: проверка не сошлась — исполнение останавливается как ошибочное [2]. Так изменение формата перестаёт быть невидимым: оно сразу становится ошибкой, которую видно.
3. Ошибка поднимает уведомление человеку. При падении исполнения запускается отдельный обработчик ошибок, который отправляет сообщение ответственному — в мессенджер, на почту или в тикет-систему [2]. Один и тот же обработчик можно привязать к нескольким workflow. Время обнаружения сбоя здесь измеряется минутами.
4. Раз в неделю — сверка счётчиков. Сколько заявок отправил сайт и сколько лидов создала CRM. Расхождение — сигнал разбираться, даже если ни одна проверка не сработала. Эта проверка грубая, зато честная: она смотрит на всю цепочку целиком и не зависит от того, что именно сломалось.
Условный пример, чтобы показать разницу. Интернет-магазин передаёт около тридцати заявок в день вебхуком в CRM. В пятницу подрядчик обновляет форму — и поле «телефон» начало передаваться с маской, которую CRM отклоняет. Половина заявок перестала доезжать. Без контроля магазин узнаёт об этом в понедельник от клиентов. С контролем — в пятницу через минуту после обновления: первая же заявка вернула ошибку, проверка ответа прервала исполнение, обработчик отправил уведомление. Разница не в том, сломалось или нет — сломалось в обоих случаях. Разница в том, сколько заявок успело потеряться.
Когда такой контроль не нужен
При пяти–десяти заявках в месяц и менеджере, который читает почту руками, обвязка не окупит время на настройку. Достаточно раз в неделю глазами сравнить два списка — отправленные формы и карточки в CRM.
Оправдана автоматизация контроля становится тогда, когда поток устойчив и заявка привязана к деньгам: платная реклама, лидогенерация, входящие обращения с сайта. В этой ситуации потерянное обращение — уже потраченный рекламный бюджет, который вернёт только повторный показ.
Пять вопросов подрядчику
Если интеграцию настраивает подрядчик, контроль доставки — его зона ответственности. Спрашивать об этом стоит до подписания, а не после инцидента.
- Что считается успешной доставкой заявки — код ответа или созданная запись в CRM?
- Что произойдёт, если CRM ответит ошибкой 503 или не ответит за отведённое время?
- Куда и кому придёт уведомление, если передача сломается?
- Как сверить число отправленных заявок с числом созданных карточек?
- Где журнал передач и как по нему установить, что и когда изменилось?
Подрядчик с готовыми ответами, скорее всего, уже встроил проверку ответа и алерты. Тем же списком стоит проверить интеграцию после сдачи и после каждого обновления формы или CRM. Отсутствие ответов — не повод отказываться от интеграции, но повод дописать контроль в договор и принять его отдельно.
Обратная сторона той же проблемы
Сбой передачи заявки направлен в одну из двух сторон: заявки теряются или размножаются. Дубли — повторные сделки из-за тайм-аутов и повторных вебхуков — разобраны в отдельном материале о дублях заявок в CRM. Требование в обоих случаях одно: одна заявка должна иметь один итоговый результат независимо от числа попыток.
И последнее. Контроль доставки — задача правил и проверок, детерминированного workflow. ИИ здесь не нужен и даже вреден: он добавил бы неопределённость в место, где нужен гарантированный результат. ИИ уместен дальше по цепочке — квалифицировать заявки, приоритизировать, отвечать клиенту, — но только когда заявка гарантированно доходит до системы. Где проходит граница между правилами и ИИ, разобрано в статье об автоматизации с помощью ИИ.
Вывод
Интеграция «сайт → CRM» — не разовая настройка, а процесс, который должен сам сообщать о поломке. Минимальная обвязка: проверка ответа на каждом запуске, уведомление ответственному при ошибке и еженедельная сверка счётчиков.
Первый шаг: выпишите все точки, где заявка передаётся автоматически — форма, вебхук, роботы CRM — и для каждой ответьте, кто и через сколько минут узнает о сбое. Там, где ответ «никто и никогда», и теряется выручка. Когда точек много и карта передач не сходится, её снимают за один проход — это часть аудита процесса.
Частые вопросы
Форма работает, но менеджер иногда не видит заявки. С чего начать проверку?
Со сверки «отправлено — создано»: посчитать заявки на стороне сайта и лиды в CRM за одну и ту же неделю. Если цифры расходятся, часть заявок не сохранилась в CRM: открыть журнал передач и повторить сценарий контрольной заявкой, чтобы увидеть, на каком шаге данные пропадают.
Достаточно ли настроить уведомление об ошибке?
Уведомление ловит явные падения. Но часть поломок ошибок не создаёт: API отвечает успешно, а формат данных изменился. Поэтому ответ внешней системы нужно дополнительно проверять на ожидаемую структуру и самому прерывать исполнение при нарушении — иначе беззвучная поломка пройдёт мимо алерта.
Нужен ли отдельный сервис мониторинга интеграций?
Мониторинг заявок в одном процессе — форма, вебхук, CRM — чаще всего закрывается встроенными механизмами платформы и еженедельной сверкой счётчиков. Отдельный сервис оправдан, когда интеграций много и по каждой нужен независимый контроль с историей. Для ИИ-ассистента задача шире — там следят за качеством ответов и трассой целиком; этому посвящена отдельная статья о мониторинге ИИ-ассистента.
Почему заявки дублируются при повторной отправке?
Потому что отправитель не получил подтверждения и повторяет попытку, а CRM создаёт карточку на каждую. Как сделать, чтобы одна заявка имела один результат независимо от числа попыток, — отдельный разбор о дублях заявок.
Что делать, если вебхук не работает?
Начать с журнала доставок на стороне отправителя: там видно, отвечал ли приёмник и чем закончилась каждая попытка. Приёмник должен отдавать успешный ответ быстро — за секунды, а не за минуты; если он лежал дольше, часть событий ушла после исчерпания повторов, и их досылают вручную или повторной передачей за период. После инцидента стоит вернуть контроль на место: валидация ответа и уведомление об ошибке, чтобы следующий сбой поднял алерт, а не ждал звонка клиента.
