ИИ-консультант для магазина на Битриксе: что подключить и как проверить

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

Разберём, какое решение выбрать для интернет-магазина на «1С-Битрикс: Управление сайтом», что подключать к каталогу и как принять работу. Битрикс24 с его CRM и помощниками для сотрудников — отдельный продукт. Наличие ИИ в CRM само по себе не даёт консультанту доступ к товарам и заказам сайта.

Сначала определите, на какие вопросы магазин теряет время

Возьмите недавние переписки и разберите хотя бы 50 обращений. Это рекомендуемый объём первого разбора, а не условие конкретного сервиса. Отметьте повторяющиеся вопросы, обращения вне рабочих часов и случаи, в которых менеджер искал информацию в нескольких системах. Отдельно посчитайте диалоги, после которых действительно появился заказ.

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

Что можно взять готовым: пример Jivo

У Jivo есть два разных сценария. ИИ-ассистент помогает оператору подготовить ответ. ИИ-оператор отвечает самостоятельно, использует добавленные источники и может передавать разговор сотруднику. В инструкции есть отдельная проверка ответов до подключения к рабочему каналу.

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

Установка Jivo на Битрикс предусмотрена через модуль или код в шаблоне. Установка виджета и подключение актуальных данных каталога — разные работы. Во втором случае разработчик должен показать, откуда консультант получил цену и наличие конкретного торгового предложения.

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

Как дать консультанту доступ к товарам и не устареть на следующий день

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

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

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

Для разработки собственной логики можно рассмотреть Yandex AI Studio или GigaChat. У Яндекса есть инструменты поиска по файлам и сайтам, у GigaChat описана работа с функциями. Эти возможности дают основу интеграции. Правила доступа, запросы к Битриксу и обработку отказов должна реализовать команда проекта.

Где консультант обязан остановиться

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

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

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

Приёмка на вопросах, на которых бот может ошибиться

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

• Нужного размера нет; у другой модели он есть. Консультант различает предложения и даёт правильные ссылки.
• Цена изменилась после загрузки базы. В ответе используется актуальная цена с учётом прав покупателя.
• Совместимость не подтверждена. Бот не додумывает её по названию и передаёт вопрос специалисту.
• Сервис каталога не отвечает. Клиент видит понятное ограничение, обращение сохраняется.
• Клиент просит человека. Диалог приходит сотруднику вместе с контекстом, без необходимости пересказывать всё заново.
• Покупатель пытается получить чужой заказ или изменить правила ответа. Данные и права остаются защищены сервером.

На проверке фиксируют неверные рекомендации, правильность передачи сотруднику и время, которое менеджер тратит на исправление. Гладкий текст сам по себе не подтверждает качество консультации.

Как посчитать пользу и запустить ограниченный пилот

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

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

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

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