Чат-бот на сайте: клиент закрыл вкладку — заявка не потеряна
Заявка теряется, когда чат-бот хранит переписку только в оперативной памяти браузерной сессии и не пишет промежуточные ответы клиента в базу до нажатия финальной кнопки «отправить». Закрыл вкладку на середине диалога — весь набранный текст, телефон и вопрос ушли в никуда. Решение — сохранять каждый шаг диалога в CRM или БД сразу, а не пакетом в конце.
Почему возникает потеря заявки при закрытии вкладки
Отдел продаж московской компании, которая торгует стройматериалами, полтора месяца жаловался руководителю: с сайта приходит трафик, чат-бот отвечает на вопросы про наличие и доставку, а заявок в CRM — единицы. Менеджер листает аналитику виджета: 340 открытых диалогов за месяц, 22 попавших в CRM. Остальные 318 просто исчезли.
Причина нашлась в коде виджета за один вечер. Бот собирал имя, телефон и вопрос клиента в переменных JavaScript прямо в браузере и отправлял их на сервер одним запросом — только после того, как клиент отвечал на последний вопрос сценария и нажимал «готово». Пока диалог не завершён, ни одна буква не покидала вкладку браузера. Клиент вводит телефон, отвлекается на звонок, случайно закрывает вкладку — и данные, которые уже были у него в браузере, стираются вместе с DOM-деревом страницы.
Схема отправки «одним куском в конце» экономит нагрузку на сервер, но переносит риск на самый уязвимый момент диалога — на промежуточное состояние, которое живёт только в оперативной памяти вкладки. Мобильный трафик усугубляет проблему: пользователь переключается между приложениями, браузер выгружает фоновую вкладку из памяти, и незавершённый диалог пропадает без всякого закрытия окна.
Ставка здесь не абстрактная. Каждая нераспознанная заявка — это клиент, который уже написал номер телефона, то есть прошёл дальше простого просмотра каталога. По воронке такой контакт стоит дороже клика по рекламе: он потратил время на диалог с ботом, показал намерение купить, и его просто не заметили. Для среднего бизнеса в Москве, где рекламный трафик на строительную и B2B-тематику недешёвый, тридцать потерянных заявок в месяц — это тридцать несостоявшихся сделок, о которых отдел продаж даже не узнал, чтобы перезвонить.
Как исправить потерю заявки в чат-боте
Первый шаг — перенести точку сохранения с «конца диалога» на «каждое сообщение клиента». Как только пользователь ввёл телефон или имя, эти данные должны лечь в базу отдельным запросом, а не ждать финального события. Технически это означает: у каждого шага сценария появляется свой обработчик отправки, а не единая функция сборки формы.
Промежуточное сохранение вместо финальной отправки
Практически это выглядит так: бот получил от клиента телефон — тут же создаётся или обновляется черновик заявки в CRM или в служебной таблице базы данных со статусом «диалог не завершён». Дальше клиент отвечает на следующие вопросы — черновик дополняется. Закрыл вкладку на середине — у менеджера в CRM уже лежит контакт с пометкой, что человек интересовался, но не договорил. Это не идеальная заявка, но это контакт, по которому можно перезвонить, а не пустота.
Восстановление сессии при возврате
Второй элемент — идентификатор сессии, который бот кладёт в localStorage браузера при первом сообщении клиента. Если человек вернулся на сайт с того же устройства в течение нескольких дней, виджет подхватывает сохранённый ID и продолжает диалог с того места, где остановился, а не начинает его заново с приветствия. Для сайтов на 1С-платформе, где заявка из чата зачастую должна попасть напрямую в документ CRM, эта логика решается на уровне доработки самой конфигурации — так, чтобы бот писал не в промежуточную таблицу, а сразу в объект 1С. Такие интеграции — это уже доработка 1С, а не настройка виджета: нужен код, который создаёт документ по частичным данным и обновляет его по мере диалога.
Что делать, если ошибка повторяется
Настроили промежуточное сохранение, а заявки всё равно теряются — значит, проблема не в логике бота, а в canale, через который данные идут дальше. Три места, где стоит смотреть по порядку.
- ✓Проверить, доходят ли запросы от бота до сервера вообще: открыть вкладку «Сеть» в инструментах разработчика браузера и отследить, что запрос на сохранение отправляется при каждом шаге, а не только в конце — если черновики не создаются, дело в коде виджета, а не в базе.
- ✓Проверить очередь обработки на сервере: если заявки от бота идут через промежуточный сервис или скрипт интеграции с 1С, и этот скрипт падает по таймауту при высокой нагрузке, часть черновиков не долетает до базы — это видно по логам сервиса за момент пиковой посещаемости сайта.
- ✓Проверить саму базу 1С, куда пишутся заявки: медленный отклик документов, блокировки при одновременной записи нескольких диалогов — типичный симптом нехватки ресурсов на сервере, где расположена информационная база.
Третий пункт встречается чаще, чем кажется. База 1С, рассчитанная на работу бухгалтерии и склада, начинает получать дополнительный поток записей от чат-бота — и если сервер уже работает на пределе, лишняя нагрузка проявляется как раз в виде обрывов записи на стороне интеграции. Проверить производительность самой базы можно тестом Гилёва — он показывает, укладывается ли сервер в нормативы по скорости для 1С, независимо от того, чат-бот нагружает базу или обычные пользователи.
Как предотвратить повторную потерю заявок
Разовая починка кода снимает симптом, но не гарантирует, что через полгода при росте трафика проблема не вернётся в новом виде. Три вещи держат её под контролем на постоянной основе.
| Мера | Что даёт | Когда нужна |
|---|---|---|
| Промежуточное сохранение каждого шага | Черновик заявки живёт в CRM, а не в памяти вкладки | Всегда, независимо от нагрузки |
| Мониторинг очереди интеграции с 1С | Видно обрывы записи до жалобы отдела продаж | При росте трафика с сайта |
| Достаточная мощность сервера базы 1С | Запись заявок не блокируется параллельной работой пользователей | Когда база уже нагружена бухгалтерией и складом |
| Резервный канал уведомления менеджера | Даже незавершённый диалог доходит до человека, а не только до базы | Для заявок с высокой ценой лида |
Отдельный вопрос — где физически стоит сервер с базой 1С, в которую бот пишет заявки. Если это старое офисное железо без резервирования, любой сбой сервера роняет не только 1С, но и запись новых обращений с сайта. Аренда сервера для 1С с гарантированными ресурсами снимает эту зависимость от состояния конкретного компьютера в офисе: сервер обслуживается отдельно, а нагрузка от чат-бота не конкурирует за ресурсы с закрытием месяца в бухгалтерии. Тарифы на такую аренду начинаются от 1100 рублей в месяц, выделенный сервер — от 1 100 ₽/мес за пользователя.
Если чат-бот и 1С уже связаны интеграцией, но она собрана наспех и без обработки частичных данных, разумнее не чинить точечно, а заказать доработку 1С под конкретный сценарий — с сохранением черновика заявки на каждом шаге диалога и логированием сбоев. Для компаний, где на 1С завязана вся работа с клиентами — от заявки до отгрузки — стоит сразу смотреть на внедрение 1С:Управление торговлей или 1С:ERP, где обработка входящих заявок с сайта закладывается в саму конфигурацию, а не прикручивается сбоку скриптом.
Кто должен following за состоянием базы, куда падают заявки
Часто ответственность размыта: разработчик виджета отвечает за фронтенд бота, интегратор — за то, что данные ушли на сервер, а состояние самой базы 1С не проверяет никто, пока не начнутся жалобы. Сопровождение 1С и работа системного администратора закрывают именно этот разрыв: регулярная проверка производительности базы, мониторинг блокировок при записи, обновление конфигурации 1С без остановки приёма заявок с сайта. Такое сопровождение оплачивается по факту обращения — от 3800 рублей в час, без обязательного абонемента на весь месяц.
Если компания планирует обновление 1С — переход на новую редакцию или установка обновлений безопасности — это тоже момент риска для интеграции с чат-ботом: старые API-обработчики, через которые бот писал заявки, могут перестать работать после обновления. Проверка совместимости интеграций перед обновлением экономит день на восстановление связи задним числом.
❓ Частые вопросы
Почему чат-бот не сохраняет заявку, если клиент не дошёл до конца диалога?
Обычно потому, что виджет держит все ответы клиента в памяти браузера и отправляет их на сервер одним запросом после последнего шага сценария. Закрыл вкладку раньше — данные, которых сервер ещё не получил, стираются вместе со страницей.
Можно ли восстановить диалог, если клиент вернулся на сайт через день?
Да, если бот сохраняет идентификатор сессии в localStorage браузера при первом сообщении. При повторном заходе с того же устройства виджет находит сохранённый ID и продолжает диалог с прерванного места вместо приветствия заново.
Заявки из чат-бота должны попадать сразу в 1С или сначала в отдельную базу?
Зависит от объёма трафика и от того, насколько база 1С загружена основной работой. Для небольшого потока заявок можно писать напрямую в документ 1С через доработку конфигурации; при высокой нагрузке разумнее промежуточный буфер, который переносит данные в 1С без блокировки записи для других пользователей.
Может ли слабый сервер стать причиной потери заявок от чат-бота?
Да. Если сервер с базой 1С уже работает на пределе из-за бухгалтерии и склада, дополнительная запись от чат-бота может обрываться по таймауту при пиковой нагрузке. Тест Гилёва показывает, укладывается ли сервер в нормативы скорости для 1С.
Сколько стоит настроить сохранение заявок из чат-бота без потерь?
Зависит от того, идёт речь о правке кода виджета или о доработке интеграции с 1С. Сопровождение 1С и работа системного администратора для диагностики и настройки записи заявок оплачивается от 3800 рублей в час по факту обращения.
Или позвоните: +7 906 045-28-27 — в рабочее время с 9:00 до 19:00
Остались вопросы? Нужна помощь?
Менеджеры компании с радостью ответят на ваши вопросы, произведут расчет стоимости услуг и подготовят индивидуальное коммерческое предложение.
Бесплатная консультация

