ИИ-консультант для сайта: где заканчивается виджет и начинается интеграция

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

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

Чтобы отвечать на такие вопросы, консультанту недостаточно уметь поддерживать диалог. Ему приходится работать с каталогом, остатками, ценами, CRM, личным кабинетом и другими системами компании. В этот момент ИИ-консультант перестаёт быть просто виджетом на сайте и становится частью цифровой инфраструктуры.

Что умеет ИИ-консультант без сложной интеграции

Самый простой вариант — консультант, который отвечает на основании заранее подготовленной базы знаний. Источниками могут быть страницы сайта, FAQ, инструкции, документация, описания услуг или другие материалы компании. Пользователь задаёт вопрос обычным языком, система ищет подходящую информацию и формирует ответ.

Такой сценарий подходит, если большая часть запросов носит информационный характер:

• какие услуги оказывает компания;
• как оформить заказ;
• какие существуют способы доставки;
• как работает возврат;
• какие документы нужны;
• чем отличаются продукты или тарифы.

Здесь ИИ делает доступ к информации удобнее. Пользователю не нужно искать нужный раздел сайта или угадывать формулировку запроса. Для такого консультанта действительно может быть достаточно относительно автономного решения.

Первая граница — данные, которые постоянно меняются

Представим интернет-магазин с тысячами товаров. Пользователь спрашивает: «Есть ли эта модель сейчас в наличии в Санкт-Петербурге?»

В статье о товаре или загруженном в базу знаний документе правильного ответа может не быть. Остатки меняются постоянно. То же происходит с ценами, сроками поставки, доступными слотами записи, статусами заказов и другими оперативными данными. Можно регулярно выгружать их в базу консультанта, но между двумя обновлениями информация уже способна измениться.

Если ответ должен отражать состояние бизнеса "сейчас", консультанту нужен доступ к системе, где хранится актуальное значение. Это одна из первых точек, где обычный виджет превращается в интеграционную задачу.

Консультант должен понимать, где искать разные ответы

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

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

ИИ-консультант в таком случае становится точкой входа сразу в несколько информационных систем.

Каталог товаров — уже отдельная задача

Особенно хорошо разница между виджетом и интеграцией заметна в e-commerce. Пользователь редко спрашивает только то, что дословно написано в карточке товара. Запросы могут выглядеть так:

• «Нужен насос для дома примерно 150 квадратов».
• «Покажи аналоги этой модели дешевле 20 тысяч».
• «Что из этого подойдёт для работы на улице зимой?»
• «Мне нужен такой же картридж, но для другой модели оборудования».

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

Поэтому за разговорным интерфейсом появляется обычная программная логика: поиск, фильтрация, API каталога, правила подбора и проверка результатов.

Чем выше персонализация, тем глубже интеграция

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

• «Когда привезут мой заказ?»
• «Какая у меня сейчас скидка?»
• «Повтори прошлый заказ».
• «Где счёт за август?»

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

Для B2B-проектов ситуация ещё сложнее. У одной компании могут быть несколько сотрудников с разными ролями, персональные договоры, индивидуальные цены, лимиты, доступные склады и условия оплаты. В таком случае консультант должен учитывать те же права и бизнес-правила, что и личный кабинет.

Просто подключить CRM или ERP недостаточно. Нужно ещё определить, какие данные конкретному пользователю разрешено получать через ИИ.

Авторизация становится частью архитектуры

Пока консультант рассказывает об услугах компании, знать пользователя необязательно. Как только появляются персональные данные, требуется надёжная идентификация.

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

ИИ здесь не создаёт новую модель доступа. Он должен подчиняться уже существующей.

Следующая граница — консультант начинает что-то делать

До определённого момента система только отвечает. Но естественное развитие сценария выглядит примерно так:

— Есть ли товар в наличии?
— Да.
— Тогда добавь два в корзину.

Второй запрос принципиально отличается от первого. Теперь ИИ должен не получить информацию, а изменить состояние системы.

То же самое происходит с запросами:

• «Запиши меня на пятницу».
• «Создай заявку».
• «Отправь коммерческое предложение на почту».
• «Отмени заказ».
• «Передай этот вопрос менеджеру».

Консультант превращается в интерфейс управления бизнес-функциями. И здесь особенно важно разделять понимание естественного языка и само выполнение операции.

ИИ не должен напрямую менять данные как ему захочется

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

Так архитектура остаётся управляемой: пользователь формулирует намерение → ИИ его интерпретирует → система вызывает разрешённую функцию → бизнес-логика проверяет условия → выполняется действие → результат возвращается в диалог.

ИИ отвечает за гибкость общения, но не заменяет правила самой системы.

Для действий разного риска нужны разные ограничения

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

Например, консультант может самостоятельно создать черновик заявки, но перед отправкой показать её пользователю. Или подготовить изменение заказа, а подтверждение оставить менеджеру. Это позволяет расширять возможности ИИ постепенно, не передавая ему сразу слишком много полномочий.

Интеграция с CRM меняет роль консультанта

Простой виджет заканчивает существование вместе с закрытием окна браузера. Интегрированный консультант может стать частью клиентского процесса.

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

Обратная интеграция тоже важна. Если в CRM уже существует клиент или обращение, консультант может учитывать эту информацию в разрешённых сценариях. Тогда чат перестаёт быть отдельным каналом и встраивается в общую работу с клиентом.

Но не каждый диалог нужно превращать в лид

Автоматическая передача всех пользователей в CRM быстро создаст информационный шум. Человек мог просто спросить режим работы или прочитать условия доставки. Поэтому нужно определить, в какой момент разговор действительно становится потенциальным обращением.

Сигналами могут быть запрос стоимости, подбор решения, готовность оставить контакты, просьба связаться с менеджером или заполнение обязательного набора данных. Конкретная логика зависит от бизнеса. ИИ может помочь определить контекст, но правила создания сущностей в CRM должны быть продуманы отдельно.

Передача человеку — не аварийный сценарий

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

Пользователь может задать вопрос, для которого нет достаточных данных. Может возникнуть спорная ситуация, нестандартная конфигурация продукта или запрос, который требует решения специалиста. В таком случае правильным результатом становится не очередная попытка модели сгенерировать ответ, а передача диалога человеку.

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

Отдельный вопрос — насколько можно доверять ответам

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

Нужно отдельно проверять:

• правильность фактов;
• корректность поиска;
• актуальность данных;
• соблюдение прав доступа;
• выполнение бизнес-правил;
• корректность вызова функций;
• поведение при нехватке информации;
• обработку нестандартных запросов.

Для разных типов ответа допустимый уровень риска будет разным.

Консультант должен уметь не отвечать

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

Поэтому ещё на этапе проектирования стоит определить, какие ответы разрешено генерировать, только если найден подтверждённый источник или получены данные из корпоративной системы.

Нужно разделять знания и оперативные данные

У консультанта обычно появляется несколько принципиально разных источников:

• Относительно стабильные знания: инструкции, правила, описания услуг, документация.
• Структурированные данные: товары, характеристики, филиалы, тарифы.
• Оперативная информация: остатки, статусы, текущие цены.
• Персональные данные конкретного пользователя.

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

Архитектура хорошего консультанта строится вокруг понимания этих различий.

Не всегда нужна максимальная интеграция

Из всего этого легко сделать обратный вывод: настоящий ИИ-консультант обязательно должен быть сложной системой.

Нет.

Если пользователи в основном задают типовые информационные вопросы, консультант на базе качественно подготовленных материалов может закрывать полезную задачу без доступа к CRM и ERP. Нет смысла подключать десяток систем только потому, что технически это возможно.

Интеграция оправдана тогда, когда без неё консультант не может решить важные пользовательские сценарии. Поэтому проектирование лучше начинать не со списка доступных API, а со списка реальных вопросов и действий пользователей.

Как понять необходимый уровень решения

Практически полезно идти от простого к сложному.

• Первый уровень — ответы по знаниям. Консультант помогает найти информацию, которая уже существует на сайте или во внутренних материалах.
• Второй уровень — актуальные данные. Появляются запросы к каталогу, ценам, остаткам и другим системам.
• Третий уровень — персонализация. Консультант знает авторизованного пользователя и работает с доступными ему данными.
• Четвёртый уровень — действия. Через диалог можно создавать заявки, работать с заказами, записываться на услуги или запускать другие операции.

Это не обязательная последовательность развития любого проекта. Компания может остановиться на первом или втором уровне, если именно там находится бизнес-эффект. Но такое разделение помогает понять, где заканчивается задача подключения виджета и начинается полноценная интеграционная разработка.

Начинать лучше не с интерфейса чата

Само окно консультанта — обычно одна из самых простых частей проекта. Гораздо важнее определить, какие пользовательские сценарии система должна закрывать.

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

Для одного проекта окажется достаточно базы знаний. Для другого потребуется каталог и поиск. Для третьего — CRM, ERP, личный кабинет и набор безопасных бизнес-функций. Именно поэтому два внешне одинаковых окна «Задать вопрос ИИ» могут отличаться по сложности разработки в разы.

Виджет становится интеграцией там, где начинается бизнес-процесс

Граница проходит не по технологии и не по внешнему виду.

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

Поэтому при выборе ИИ-консультанта полезнее спрашивать не «какая модель будет внутри?», а «что именно пользователь должен суметь сделать с его помощью?»

Ответ на этот вопрос и показывает, нужен компании простой виджет или полноценный интегрированный сервис.