Заявка из чата пропала в пятницу вечером: разбор цепочки сбоя

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

Почему заявки из чата не доходят до менеджера

Пятница, 19:40. Посетитель на сайте компании, которая продаёт офисную мебель оптом, открывает чат-виджет и пишет: «нужен расчёт на 40 столов, пришлите КП». Виджет показывает галочку «отправлено», диалог закрывается как обработанный, менеджер в это время уже не смотрит в CRM — рабочий день закончился.

Но в CRM менеджера в понедельник утром этой заявки нет — ни карточки, ни уведомления, ничего. За выходные клиент написал ещё в два места, и к понедельнику уже согласовывает счёт с конкурентом, который ответил первым.

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

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

У цепочки «посетитель — виджет — сервер бота — канал уведомления — CRM или 1С — менеджер» пять узлов, и подводит обычно один. Разбирать по порядку быстрее, чем винить бота целиком.

• ✓виджет на странице — конфликт с другим JS-кодом (второй чат, счётчик аналитики, старая версия скрипта после обновления сайта) блокирует отправку события;
• ✓сервер бота — вебхук не отвечает вовремя: хостинг перегружен в часы пиковой посещаемости или бот работает на том же сервере, что и сайт, и проседает вместе с ним;
• ✓канал уведомления — у Telegram Bot API и WhatsApp Business API есть лимиты на число сообщений в единицу времени, и при всплеске обращений часть уведомлений просто не уходит;
• ✓интеграция с 1С или CRM — после планового обновления 1С меняются названия полей или формат телефона, и заявка не создаётся автоматически;
• ✓дежурный менеджер — заявка долетела до CRM, но осталась без ответственного и без срока реакции.

Как исправить: проверяем каждое звено цепочки

Гадать, какое звено виновато, не нужно — цепочку проверяют по порядку, от виджета к менеджеру, и на каждом шаге видно, где именно рвётся передача.

виджет и сайт

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

сервер бота и вебхук

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

уведомления и мессенджер

Проверяем срок действия токена бота и лимиты API — Telegram и WhatsApp ограничивают частоту отправки, и при резком росте обращений, например после рекламной кампании, часть уведомлений отбрасывается молча, без ошибки на стороне сайта. Здесь помогает резервный канал: если основной мессенджер не ответил за несколько секунд, уведомление дублируется на почту.

интеграция с 1С или CRM

Самое незаметное звено: заявка технически дошла до сервера, но не создалась карточкой в 1С, потому что после планового обновления изменился формат поля «телефон» или переименовался реквизит. Если чат-бот создаёт заказы или лиды напрямую в 1С:Управление торговлей или 1С:ERP, интеграцию стоит собирать не самописным разбором ответа, а через доработку 1С с явным API-эндпоинтом — тогда обновление конфигурации не ломает передачу молча, а выдаёт понятную ошибку.

дежурный менеджер

Последнее звено — человеческое: заявка есть в CRM, но никто не назначен ответственным. Помогает простое правило — если заявка не взята в работу за 15 минут в рабочее время, система эскалирует её следующему по очереди менеджеру, а не ждёт, пока кто-то откроет CRM по привычке.

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

Хуже, когда цепочку один раз починили, а через пару недель заявки снова начинают пропадать — но не все, а через одну, и повторить сбой по требованию не получается. Такая перемежающаяся ошибка обычно указывает не на код, а на нагрузку или на внешнее изменение, которое никто не отследил, потому что оно случилось не у вас, а у поставщика API.

Первый шаг — логировать каждый узел цепочки отдельно, с меткой времени: когда виджет отправил событие, когда сервер бота его принял, когда ушло уведомление, когда лид появился в CRM. Без пошагового лога невозможно отличить «виджет не отправил» от «сервер принял, но не успел ответить», а разница между этими двумя причинами — разные исполнители и разные сроки исправления.

Второй шаг — сопоставить сбои с нагрузкой. Если заявки пропадают именно в часы, когда одновременно работают сайт, бот и учётная база на одном сервере, дело не в логике бота, а в ресурсах. Перенос интеграции на отдельный сервер, аренда от 1 100 ₽/мес за пользователя, снимает эту причину полностью: сервер бота перестаёт конкурировать за память и процессор с базой 1С в момент закрытия месяца бухгалтерией или всплеска трафика после рекламы.

Третий шаг — сверить версию API мессенджера. Telegram и WhatsApp периодически меняют лимиты и формат вебхуков, и то, что работало в марте, может молча перестать работать в сентябре без единого сообщения об ошибке на стороне бота — просто уведомления перестают доходить, а сама заявка при этом остаётся в CRM и ждёт, пока её кто-то откроет вручную.

Как предотвратить потерю заявок из чата на постоянной основе

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

• ✓мониторинг цепочки — алерт, если вебхук не ответил за несколько секунд или в CRM не появилось ни одной новой заявки за необычно долгий рабочий период;
• ✓резервный канал уведомления — дублирование в почту рядом с мессенджером, чтобы один упавший сервис не забирал все заявки разом;
• ✓проверка интеграции после каждого крупного обновления 1С — поля и реквизиты меняются молча, и разумнее протестировать интеграцию тестовой заявкой сразу после обновления, чем узнать о поломке от клиента через месяц;
• ✓регламент с фиксированным сроком реакции дежурного менеджера на новую заявку и явной эскалацией, если срок нарушен.

Отдельный момент — форма сбора данных в самом чате. Если бот запрашивает телефон или почту, эти данные подпадают под 152-ФЗ «О персональных данных»: рядом с формой нужны согласие на обработку и ссылка на политику конфиденциальности, а не молчаливый сбор контактов до отправки заявки.

Когда чинить своими силами, а когда звать интегратора

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

Мы в ukved.ru закрываем именно этот стык: диагностируем цепочку от виджета до карточки в CRM или 1С, находим узел разрыва и чиним его — по тарифу сопровождения, 3800 рублей в час, без абонентской платы за месяцы, когда ничего не сломано. Если компания вообще без учётной системы для заявок и склада, предлагаем внедрение 1С:Управление торговлей для среднего бизнеса или 1С:ERP, если компания уже выросла из простого учёта заявок и продаж и цепочка передачи лидов должна встраиваться в более крупный контур.

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

Как быстро проверить, доходят ли заявки из чата на сайте до менеджера?

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

Может ли заявка потеряться из-за обновления 1С?

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

Сколько стоит диагностика и настройка надёжной передачи заявок из чата?

Диагностика и исправление цепочки идут по тарифу сопровождения — 3800 рублей в час, без абонентской платы. Итоговая стоимость зависит от того, сколько узлов нужно проверить и есть ли готовая интеграция с 1С или её нужно строить заново.

Заявки приходят через раз — с чего начать поиск причины?

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

Нужно ли согласие на обработку персональных данных в форме чата?

Да, если бот запрашивает телефон, почту или имя клиента, это персональные данные по 152-ФЗ. Рядом с формой нужны согласие на обработку и ссылка на политику конфиденциальности — их отсутствие создаёт юридический риск отдельно от технической проблемы с доставкой заявок.