Мы в ПСБ знаем об этом не понаслышке: наши специалисты развивают ИИ-ассистента для бизнес-клиентов и на практике прошли путь от сценарного бота до RAG*. Многие выводы из этого опыта применимы и к ботам для приёма заказов — ими и поделимся в статье. Полный банковский кейс можно прочитать на ресурсе Habr.com.
*RAG (Retrieval-Augmented Generation) — подход, при котором модель ищет ответ в актуальной базе знаний.
Содержание
Зачем бизнесу бот
Внедрение бота оправдано, когда есть высокий поток однотипных вопросов — даже при небольшом ассортименте. Чем шире каталог, тем заметнее эффект.
Конкретные выгоды: круглосуточный приём заказов, снижение нагрузки на операторов (они занимаются только сложными случаями), рост конверсии за счёт мгновенных ответов, сокращение времени оформления заказа с нескольких минут до 30–40 секунд.
Конверсия в заказ при использовании бота может быть на 15–20% выше, чем при классической форме заказа. Но эти цифры достижимы только при качественной реализации. Плохо настроенный бот даст обратный эффект — об этом подробнее в разделе «Типичные ошибки».
Какой тип бота выбрать
Существует три подхода.
№1. Сценарный (rule-based)
Работает по кнопкам и фиксированным маршрутам. Прост в создании, но не понимает свободный текст. Для небольшого бизнеса с ограниченным ассортиментом (например, пиццерии) этого достаточно.
№2. LLM-based
Использует большие языковые модели (в России доступны GigaChat, YandexGPT). Понимает свободный диалог, обрабатывает неоднозначные запросы. Требует тщательной настройки, так как без ограничений (правил, не позволяющих боту выходить за рамки допустимых ответов) и привязки к актуальной базе данных через RAG может выдумывать несуществующие товары или цены.
№3. Гибридный
Оптимальный вариант для большинства бизнесов: сценарный для типовых операций + LLM для сложных случаев.
Как выбрать
Для микробизнеса с десятками позиций — сценарный бот. Для среднего бизнеса (100–1000 товаров, типовые сценарии и потребность в консультациях) — гибридный. Для крупного (тысячи товаров, сложные диалоги, бюджет на разработку) — LLM-based с RAG.
Ориентиры по стоимости и срокам
Сценарный бот на конструкторе — 30–50 тыс. рублей, запуск за 1–2 недели.
Гибридный с интеграциями — от 300 тыс. до 1 млн рублей, 1–3 месяца.
LLM с RAG и кастомной разработкой — от 1 млн рублей, 3–6 месяцев.
Расценки и сроки ориентировочные и зависят от сложности интеграций и выбранного подрядчика.
Проектирование: сценарии и диалоги
Ключевые сценарии: поиск товара → добавление в корзину → оформление → оплата → отслеживание. Для каждого сценария нужно продумать «основной путь» и альтернативные ветки: товара нет в наличии, некорректный адрес, клиент передумал.
Перевод на оператора: бот должен уметь распознавать моменты, когда не справляется, и передавать диалог человеку с сохранением контекста.
Когда передавать: после двух неудачных попыток понять запрос, при явной просьбе «поговорить с человеком», при нестандартной ситуации, не описанной в сценариях. Возможность выйти на оператора должна быть доступна в любой момент по ключевым словам «оператор», «помощь», «человек».
Примеры диалогов
Удачный заказ: «Хочу пиццу Маргариту» → «Большую или среднюю?» → «Среднюю» → «Добавил в корзину. Что-то ещё?» → «Всё» → «Оформляем? Адрес доставки?».
Товар закончился: «Добавь HUAWEI nova 15 Pro» → «Извините, этой модели сейчас нет. Есть HUAWEI nova 14 Pro. Хотите посмотреть характеристики?».
Размытый запрос (сценарный бот): «Хочу что-то вкусное и недорогое» → «Уточните, пожалуйста. Выберите категорию: пицца, роллы, салаты» → (клиент не выбрал) → «Переключаю на оператора, он поможет подобрать».
Тот же запрос (LLM-бот): «Хочу что-то вкусное и недорогое» → «Вот три самых популярных блюда до 500 ₽: пицца Маргарита (399 ₽), ролл Филадельфия (449 ₽), салат Цезарь (349 ₽). Что добавить в корзину?»
Тон общения должен соответствовать бренду. Бот не должен притворяться человеком. Лучше сразу представиться: «Я виртуальный помощник, помогу с заказом».
Техническая архитектура
Каталог и база товаров
Бот интегрируется с каталогом в реальном времени. Он знает наличие, цены, характеристики. Подключается напрямую к базе или через API. Данные обновляются с минимальной задержкой.
Понимание запросов
Для сценарного бота достаточно кнопок и ключевых слов. Для LLM и гибридного подхода настраивают определение намерений («хочу заказать», «где мой заказ», «отменить») и извлечение сущностей (названия товаров, количество, адрес, дата). LLM упрощает задачу, но результат стоит валидировать и переспрашивать при неоднозначности.
Корзина и оформление
Бот умеет добавлять товары, менять количество, удалять позиции, показывать корзину и рассчитывать итоговую сумму со скидками и доставкой. Последовательность: подтверждение корзины → адрес → дата и время → способ оплаты → финальное подтверждение.
Платежи
Бот подключается к платёжному провайдеру — это может быть как внешний сервис, так и эквайринг вашего банка. Данные карты клиент вводит на защищённой странице банка, бот их не обрабатывает и не хранит.
Уведомления
Клиент получает сообщения о смене статуса: заказ принят → в сборке → передан курьеру → доставлен. Статус можно запросить в любой момент командой «Где мой заказ?».
Выбор канала
Мессенджеры и виджеты на сайте. Для бизнеса без команды разработчиков есть no-code и low-code конструкторы. Начните с одного канала, где сосредоточена основная аудитория, и расширяйтесь по мере роста.
Безопасность
Помимо защиты персональных данных (об этом — в юридическом разделе), стоит учитывать три риска.
№1. Prompt injection
Пользователь пытается «взломать» бота специальными запросами, чтобы изменить его поведение: обойти ограничения, подменить цены, заставить бота действовать вопреки правилам.
Защита: фильтрация входящих сообщений, разделение системного промпта и пользовательского ввода, тестирование на типовые атаки перед запуском.
№2. Фрод
Массовые фейковые заказы через бота.
Защита: лимиты на количество заказов с одного аккаунта, подтверждение по SMS или email, CAPTCHA при подозрительной активности.
№3. Утечка внутренней логики
Бот может раскрыть конфиденциальную информацию: системный промпт, бизнес-правила, внутренние данные — даже без целенаправленной атаки, просто в ответ на неожиданный вопрос.
Защита: не помещайте конфиденциальную информацию в системный промпт, выносите бизнес-логику на серверную сторону, регулярно тестируйте бота на попытки извлечения.
Типичные ошибки и как их избежать
№1. Галлюцинации LLM
Бот выдумывает несуществующие товары, цены, характеристики.
Что делать: привязка к актуальной базе через RAG, валидация ответов, правила. Цены — только из каталога, никогда не генерируются моделью.
№2. Этический фильтр модели
LLM может блокировать запросы из-за формулировок в описаниях товаров (ножи, алкоголь, лекарства, товары для взрослых).
Что делать: тестировать весь каталог на прохождение фильтров, при необходимости переформулировать описания или использовать сценарный подход для проблемных категорий.
№3. «Мёртвый» бот
Запустили и забыли. Каталог устарел, сценарии не обновляются, обратная связь не собирается.
Что делать: назначьте ответственного за обновление сценариев минимум раз в неделю.
№4. Бот снижает конверсию
Если бот работает хуже, чем простая форма заказа, он вредит бизнесу.
Что делать: замерьте базовую конверсию до запуска и сравните после. Если показатели упали — дорабатывайте или откатывайтесь.
№5. Попытка охватить всё сразу
Стремление покрыть весь ассортимент и все сценарии вместо пилота.
Что делать: начните с самых популярных товаров и ключевых сценариев.
Юридический минимум
152-ФЗ (персональные данные)
Перед сбором имени, адреса, телефона бот показывает ссылку на политику обработки персональных данных и получает явное согласие (кнопка «Я даю согласие на обработку моих персональных данных»). Данные хранятся в защищенном контуре. Клиент может запросить удаление своих данных в любой момент.
54-ФЗ (онлайн-кассы)
Продавец обязан обеспечить выдачу чека при приёме оплаты. При автоматизации через бота это реализуется интеграцией с онлайн-кассой. Чек отправляется клиенту в чат или на email. За невыдачу чека предусмотрен штраф. Фискальные данные передаются в ОФД в соответствии с требованиями 54-ФЗ.
Статья 26.1 ЗоЗПП (дистанционная торговля)
До оформления заказа бот информирует о полной стоимости, условиях доставки, правилах возврата товара. Эта информация доступна по запросу и в процессе оформления. Клиент вправе отказаться от заказа до оплаты, отправив сообщение «Отмена».
Закон о рекламе
Если бот отправляет промо-рассылки, нужно получить отдельное согласие клиента на рекламу и дать возможность отписаться одним сообщением («стоп», «отписаться»).
Ответственность за ошибки бота
Неверная цена или некорректная информация о товаре — ответственность на продавце, не на алгоритме. Клиент может ссылаться на цену, названную ботом, и судебная практика в ряде случаев встаёт на сторону покупателя. Это ещё один аргумент строгой валидации ответов (подробнее — в разделе «Типичные ошибки»).
Метрики и аналитика
Без аналитики невозможно понять, работает бот или вредит. Метрики закладываются до запуска бота, а не после.
Ключевые метрики:
- конверсия в заказ (сравниваем с периодом без бота);
- процент отказов на каждом шаге оформления;
- доля эскалаций на оператора (слишком высокая — бот не справляется, слишком низкая — возможно, не передаёт сложные случаи);
- среднее время оформления заказа;
- CSAT (Customer satisfaction score — показатель удовлетворённости клиентов) — короткий опрос после завершения диалога.
Возвращаясь к опыту ПСБ, о котором мы упоминали в начале: сценарный бот обрабатывал типовые операции, а RAG+LLM взяли на себя консультации по продуктам. Результат: доля автоматически решённых обращений выросла на 7%, удовлетворённость клиентов — на 21%, среднее время решения вопроса сократилось в 8 раз.
Чек-лист запуска
1. Определите целевые сценарии (3–5 основных) и правила эскалации на оператора.
2. Выберите тип бота под свой масштаб и бюджет.
3. Подключите каталог товаров с обновлением в реальном времени.
4. Настройте понимание запросов и валидацию ответов (особенно цен).
5. Реализуйте корзину и пошаговое оформление.
6. Интегрируйте платежи с соблюдением 54-ФЗ.
7. Настройте уведомления о статусах заказа.
8. Выполните юридические требования(152-ФЗ, ЗоЗПП, согласие на рекламу).
9. Проведите тестирование:
– пройдите все сценарии сами,
– дайте протестировать 5–10 реальным клиентам,
– проверьте на prompt injection.
10. Заложите метрики и замерьте базовые показатели до запуска.
11. Запланируйте сбор обратной связи и регулярные итерации (минимум раз в неделю).
Вывод: главный принцип — поэтапность. Не пытайтесь автоматизировать всё сразу. Запустите минимальный работающий сценарий, убедитесь, что он приносит пользу, и только потом расширяйте.
