Бот вежливо здоровается, а не отвечает на вопрос о цене: как чинить

Бот отвечает вежливо, но мимо вопроса, когда сценарий не покрывает формулировку клиента или бот не видит актуальных данных — остатков, цен, статуса заказа — в учётной системе. Лечится это ревизией базы интентов, точной настройкой fallback-логики и правильной интеграцией с 1С, откуда бот берёт факты, а не подбирает общий ответ.

почему бот отвечает вежливо, но не по делу

Клиент пишет боту на сайте оптовой компании в четверг вечером, без пяти десять: «есть в наличии профиль 60х40 на складе в Одинцово?» Бот отвечает: «Спасибо за обращение! Уточните, пожалуйста, какой товар вас интересует» — хотя название товара уже стоит в первом же сообщении.

Но дело не в вежливости — тон бота настроен ровно так, как задумал маркетолог. Проблема в том, что бот либо не распознал «профиль 60х40» как товарную позицию, либо распознал верно, но не смог свериться с остатками на складе и откатился на дежурную фразу. Клиент не станет ждать до утра: он открывает сайт конкурента и пишет туда же самое сообщение. Заявка, за которую компания заплатила рекламой, пропадает молча — менеджер утром даже не узнает, что диалог сорвался, если логи никто не читает.

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

что происходит внутри бота в этот момент

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

если бот подключён к 1С — отдельная причина

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

как исправить: бот отвечает мимо вопроса

Чинить стоит по порядку — от диагностики к правке сценария и только потом к интеграции, иначе легко потратить время на симптом вместо причины.

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

поднять журнал диалогов, а не полагаться на ощущение

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

расширить базу интентов и синонимов

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

сделать fallback конкретным действием, а не отпиской

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

проверить сценарий на реальных диалогах перед публикацией

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

дать боту доступ к реальным данным из 1С

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

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

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

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

как предотвратить повторные промахи бота

Разовая правка снимает симптом на один сезон. Чтобы бот не «тупел» через месяц, нужен регламент, а не разовая доработка.

чек-лист для регулярной проверки

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

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

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

Такую регулярную проверку логов и синхронизацию с 1С мы обычно берём на сопровождение: специалист разбирает диалоги, при необходимости донастраивает обмен или дорабатывает сценарий. Ставка та же, что и на остальное сопровождение 1С и системное администрирование — от 3800 руб/час, без отдельного тарифа «для бота».

где искать причину: симптом → причина

Прежде чем чинить сценарий, полезно свериться с типовыми парами: что видно снаружи и что сломано внутри.

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

Почему бот на сайте отвечает вежливо, но игнорирует конкретный вопрос?

Чаще всего срабатывает запасной fallback-сценарий: бот не распознал формулировку вопроса как известное намерение или распознал верно, но не смог получить данные — остаток, цену, статус заказа — из учётной системы, и вместо ответа выдаёт общую вежливую фразу.

Можно ли исправить бота своими силами, без разработчика?

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

Почему бот снова начинает отвечать не по делу через месяц после исправления?

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

Бот просит оставить телефон, если не может ответить — это законно?

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

Сколько стоит доработать бота под интеграцию с 1С?

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