Самая простая версия ИИ-чата выглядит эффектно на демо: пользователь пишет вопрос, модель отвечает
В реальной компании этого мало
Консультант должен знать актуальные товары и материалы, не придумывать то, чего нет на сайте, понимать границы своей роли, уметь передать разговор человеку и потом не мешать оператору
И главное — пользователь не должен замечать, что за одной маленькой кнопкой чата переключаются несколько систем
ИИ не должен жить в вакууме
Мария получает подготовленный снимок содержимого магазина: каталог, документы, материалы и другие публичные данные
Это важнее, чем попытка «научить модель РЕТОНу» один раз большим системным промптом
Содержимое сайта меняется. Значит, консультант должен опираться на то, что реально опубликовано сейчас
Если точного подтверждения цены, наличия или факта нет, лучше отправить человека в соответствующий раздел, чем красиво выдумать ответ
Не каждый запрос вообще должен идти в большую модель
Часть вопросов предсказуема:
- где доставка
- где документы
- как выбрать товар
- как перейти к диагностике
- как связаться с человеком
Для таких сценариев полезнее детерминированная маршрутизация
Она быстрее, стабильнее и лучше контролируется. Генеративная модель включается там, где действительно нужен свободный ответ
Так чат становится не «LLM на все случаи», а комбинацией понятных правил и модели
Передача оператору — отдельный бизнес-процесс
Фраза «сейчас позову человека» ничего не стоит, если после неё диалог теряется
В рабочем контуре передача означает реальную связь с операторской частью Bitrix24
Упрощённо:
чат сайта → Мария → запрос оператора → Открытая линия → оператор
После этого ответ оператора возвращается обратно в тот же пользовательский чат
Человек не должен открывать другую форму, начинать разговор заново или пересказывать, что только что обсуждал с ИИ
Контекст нужен с обеих сторон
При передаче важно сохранить:
- сессию пользователя
- историю диалога
- причину передачи
- связь с операторским тредом
- новые сообщения оператора
Для этого существует отдельное состояние и сопоставление между сайтом и Open Lines
Это тот слой, который обычно отсутствует в красивых демонстрациях «ИИ + CRM», но именно он делает интеграцию рабочей
Когда нужен лид в CRM
Не каждый вопрос в чате должен создавать лид
Если человек просто спросил про доставку, CRM-запись может быть лишним шумом. Но если консультация дошла до реального интереса и контактов, обращение можно передать в CRM как отдельную сущность
В РЕТОН этот путь вынесен отдельно от самого чата, чтобы коммуникация и CRM-запись не были одним обязательным действием
Защита от петель и странных запросов
После подключения оператора появляется ещё одна техническая опасность: система может принять собственное сообщение за новое входящее и начать отвечать сама себе
Поэтому нужны:
- различение источников сообщений
- защита от echo
- ограничение повторных маршрутов
- защита от prompt injection и низкосигнальных запросов
- контроль источника ответа
Вокруг чата есть отдельные smoke- и regression-проверки именно на такие сценарии
Мониторинг ИИ тоже должен быть продуктовым
Недостаточно знать, что процесс Python запущен
Полезно видеть, сколько запросов прошло, каким источником был сформирован ответ, какой маршрут выбрал чат, какая модель использовалась и не выросло ли количество fallback-сценариев
Так можно заметить деградацию раньше, чем она превратится в поток странных диалогов
Итог
Мария для меня — не «бот на Claude»
Это связка из содержимого магазина, маршрутизации, генеративной модели, защитных правил, операторского контура и CRM
И самая важная часть здесь не интеллект модели, а правильный переход между автоматикой и человеком