Чем ИИ-бот на знаниях сайта отличается от бота со сценариями

Бот со сценариями отвечает только по прописанным веткам: «если клиент написал X — показать Y», шаг в сторону от сценария — и бот теряется. ИИ-бот на знаниях сайта читает каталог, статьи и прайс как обычный текст, формулирует ответ своими словами и не привязан к дереву вопросов: работает и с формулировками, которых в базе никогда не было.

сценарный бот и бот на знаниях: разная механика под капотом

Бот со сценариями — это конструктор веток. Оператор или маркетолог заранее прописывает: клиент нажал «доставка» — бот показывает текст про сроки; клиент нажал «оплата» — бот показывает реквизиты. Всё, что не попало в список кнопок или ключевых слов, бот распознаёт как «не понял вопрос» и либо зацикливается, либо переключает на человека. Логика жёсткая, предсказуемая и дешёвая в запуске — но живёт ровно в границах того, что в неё заложили.

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

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

тест на живых вопросах: где сценарий ломается

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

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

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

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

сравнение в цифрах: где какой бот выигрывает

Разница заметнее, если сопоставить оба подхода не абстрактно, а по тому, что видно на реальных проектах клиентов малого и среднего бизнеса в Москве — по времени запуска, охвату вопросов и рискам.

Для бизнеса это переводится в конкретику: если сайт получает около 300 обращений в чат за месяц и треть из них нетиповые, сценарный бот закрывает вопрос не более чем в 200 случаях, а оставшиеся 100 диалогов либо ждут оператора, либо срываются. ИИ-бот эту разницу забирает себе, но выигрыш ощутим только если база знаний реально содержит ответы на нетиповые вопросы, а не общий текст «звоните нам».

сколько стоит содержать каждый вариант

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

Условный пример: у магазина стройматериалов на 800 позиций в сценарном боте пришлось бы держать больше 40 веток и переписывать их при каждой сезонной акции — это часы работы контент-менеджера каждую неделю. У того же магазина ИИ-бот подхватывает изменения цен и наличия сразу с сайта, без участия человека: правки нужны, только если меняется сама структура каталога, а не отдельные позиции.

ИИ-бот на знаниях требует больше работы на старте: собрать и разметить базу (сайт, прайс, инструкции, частые вопросы из переписок), протестировать на реальных диалогах, ограничить, чтобы бот не отвечал за пределами загруженных источников. Дальше стоимость поддержки зависит не от числа товаров, а от того, нужны ли боту живые данные из учётной системы — остатки, статус заказа, персональная скидка. Это уже не контент-правки, а разработка на стороне 1С, и такие работы у нас считаются по часам сопровождения 1С и системного администрирования — от 3800 руб/час, в зависимости от объёма интеграции.

когда сценарный бот всё ещё выигрывает

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

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

На практике рабочая схема часто гибридная: первый слой — сценарный триаж («по какому вопросу обращаетесь: заказ, доставка, гарантия»), а уже внутри выбранной ветки, если вопрос сложнее галочки, подключается ИИ-бот на знаниях сайта. Так меньше риска, что клиент с типовым вопросом получит развёрнутый, но случайно неточный ответ там, где хватило бы простой кнопки.

как бот дотягивается до данных 1С — и почему это меняет разговор с клиентом

Даже лучший ИИ-бот на знаниях сайта отвечает по тексту, который ему загрузили: описанию товара, условиям доставки, статьям. А вопрос «сколько сейчас на складе» или «на какой стадии мой заказ №4521» требует не текста, а живого запроса в учётную систему — и вот тут разговор с сайта-визитки переходит в разговор с 1С.

Чтобы бот мог отвечать по остаткам, ценам с учётом скидки клиента или статусу заказа, нужен API-мост в базу 1С — отдельная доработка 1С, которая открывает боту только нужные данные, без прямого доступа к базе. Процесс обычно такой: сначала считаем, какие именно данные бот должен доставать — остатки, цену, статус заказа, историю покупок клиента; затем на стороне 1С делаем отдельный сервис с ограниченным набором методов только под эти задачи; и уже потом ИИ-бот обращается к этому сервису, а не напрямую к базе, — так проще контролировать, что именно бот может показать постороннему человеку в чате.

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

Для бизнеса разница ощутима не в технологиях, а в том, что клиент слышит в ответ: «уточню у менеджера» или конкретную цифру прямо в чате, за секунды, в любое время суток.

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

Сколько времени занимает запуск ИИ-бота на знаниях сайта?

От 2 до 3 недель: неделя уходит на сбор и разметку базы (сайт, прайс, частые вопросы), ещё одна-две — на тестирование по реальным диалогам и ограничение ответов только загруженными источниками, без домыслов бота.

Может ли ИИ-бот придумать неверный ответ клиенту?

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

Можно ли совместить сценарного бота и ИИ-бота на одном сайте?

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

Бот может подсказать остаток товара или статус заказа из 1С?

Только если для этого сделан отдельный API-мост в 1С. Без него бот отвечает по статичному описанию на сайте, а не по актуальным данным склада или заказа.

Что бот делает с телефоном или почтой, которые клиент оставляет в чате?

Это персональные данные, их обработка подчиняется 152-ФЗ: хранить такие диалоги нужно с учётом требований закона, а не просто сохранять в общий лог переписок.