Новости

Внедрение ИИ-чат-бота в бизнес: что происходит до и после запуска

Вопрос покупателя «есть ли этот товар в нужном магазине и можно ли его забронировать» выглядит простым только со стороны клиента.

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

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

Ниже разберем, из каких этапов состоит такой проект.

Сначала определяется, какую задачу должен решать чат-бот

Формулировка «нужен бот, который отвечает клиентам» не подходит для начала разработки. Клиенты обращаются по разным причинам, а каждый тип запроса требует своих данных и действий.

Для розничной компании это могут быть:

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

Сначала для каждого направления определяют, каким результатом должен закончиться диалог.

Определим, какие обращения стоит передать чат-боту

Разберем основные вопросы клиентов и выделим сценарии, с которых целесообразно начать внедрение - https://sowita.kz/ai-business-kazakhstan

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

Рабочая карта сценариев может выглядеть так:

Обращение клиента	Что делает чат-бот	Источник информации	Когда нужен сотрудник
Наличие товара	Уточняет товар и магазин, запрашивает остаток	Учётная система или каталог	Товар не удалось определить или данные недоступны
Статус заказа	Проверяет клиента и получает текущий статус	CRM или система управления заказами	Статусы в системах расходятся
Условия возврата	Уточняет параметры покупки и показывает подходящее правило	Утверждённая политика возврата	Нестандартная ситуация или претензия
Вопрос по бонусам	Получает доступный баланс или объясняет правила начисления	Система лояльности и база знаний	Требуется корректировка операции
Подбор товара	Собирает требования и выполняет поиск по каталогу	Каталог товаров	Клиенту нужна консультация специалиста

Разбираются реальные обращения клиентов

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

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

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

Так выявляется не только содержание будущих ответов, но и фактический маршрут обращения внутри компании.

На этом этапе важно найти:

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

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

Проверяется, откуда компания берет правильный ответ

После анализа обращений составляют карту источников.

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

Источники разделяют на две группы.

Постоянная информация

К ней относятся сведения, которые меняются относительно редко:

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

Такую информацию можно подключить к базе знаний чат-бота.

Изменяемые данные

К ним относятся:

цены;
остатки;
статус заказа;
состав и состояние корзины;
начисленные бонусы;
индивидуальные условия клиента;
доступные интервалы доставки;
данные по резервированию.

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

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

Готовится база знаний

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

Для этого:

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

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

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

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

Проверим, готова ли ваша компания к запуску чат-бота

https://sowita.kz/audit-avtomatizacii-biznesa/

Проектируется диалог, а не только текст ответа

Правильная информация ещё не гарантирует, что клиент решит вопрос.

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

В сценарии заранее определяют:

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

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

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

Без этого чат-бот не сокращает путь клиента, а добавляет ещё один этап перед разговором с человеком.

Чат-бота подключается к системам компании

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

В зависимости от задачи чат-бот может обращаться к:

1С или другой учётной системе;
CRM;
системе управления заказами;
товарному каталогу;
сервису доставки;
программе лояльности;
системе поддержки;
сервису записи или бронирования;
личному кабинету клиента.

Архитектура проекта в упрощённом виде выглядит так:

Сайт или мессенджер → обработка сообщения → база знаний и правила диалога → информационные системы → ответ клиенту или передача сотруднику

Все операции делят на чтение и изменение данных.

Получить статус заказа или проверить остаток — это чтение. Создать заказ, оформить резерв, изменить контактные данные или применить бонусы — изменение.

Для операций второго типа отдельно настраивают:

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

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

Собирается тестовый набор из реальных вопросов

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

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

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

Для каждого теста фиксируют:

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

Проверяется не красота формулировки, а результат:

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

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

Определяются правила работы с персональными данными

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

Не следует передавать модели всю карточку клиента, если для ответа достаточно номера и статуса заказа.

В проекте предусматривают:

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

Для компаний, работающих в Казахстане, сбор, обработка и защита персональных данных должны быть организованы в соответствии с законодательством Республики Казахстан. Закон предусматривает требования к цели обработки, согласию субъекта и защите данных, а действующие правила требуют определить бизнес-процессы, в которых используются персональные данные, и применять правовые, организационные и технические меры защиты. Конкретную схему обработки следует согласовать с юристом и специалистом по информационной безопасности.

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

Запускается ограниченный пилот

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

Для пилота выбирают контролируемый контур, например:

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

На реальных обращениях оценивают:

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

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

После исправлений повторяют тестирование и только затем расширяют контур.

После запуска начинается сопровождение

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

Поэтому для чат-бота назначают владельцев:

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

В рабочем режиме отслеживают:

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

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

Что получает бизнес после внедрения

Результат проекта — не только окно чата.

В состав работающего решения входят:

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

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

От чего зависит стоимость внедрения ИИ-чат бота

На объём проекта влияют:

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

Бот, который отвечает по утверждённым материалам, и система, которая проверяет остатки, оформляет резерв и изменяет заказ, — разные по составу проекты, даже если для клиента оба решения выглядят как одно окно переписки.

Когда чат-бот не нужен

Иногда задачу можно решить без разработки ИИ-чат-бота.

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

Не стоит начинать внедрение, если:

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

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

С чего начать проект

Для первичной оценки полезно подготовить:

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

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

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

Запишитесь на диалог с экпертами SOWITA - мы бесплатно оценим объем работ и дадим предварительную оценку проекта - https://sowita.kz/ai-business-kazakhstan

2026-07-29 14:00 ИИ для бизнеса