Вопрос покупателя «есть ли этот товар в нужном магазине и можно ли его забронировать» выглядит простым только со стороны клиента.
Чтобы ответить, чат-боту нужно определить товар и магазин, получить актуальный остаток, проверить правила резервирования и сообщить результат. Если товара нет, система должна предложить допустимый следующий шаг, а не придумать наличие или пообещать действие, которое не было выполнено.
Поэтому внедрение ИИ-чат-бота - это не установка виджета на сайт и не подключение языковой модели. Это работа с клиентскими обращениями, внутренними документами, учетными системами, правилами обслуживания и ответственностью сотрудников.
Ниже разберем, из каких этапов состоит такой проект.
Ниже разберем, из каких этапов состоит такой проект.
Сначала определяется, какую задачу должен решать чат-бот
Формулировка «нужен бот, который отвечает клиентам» не подходит для начала разработки. Клиенты обращаются по разным причинам, а каждый тип запроса требует своих данных и действий.
Для розничной компании это могут быть:
- наличие и характеристики товара;
- адреса и график работы магазинов;
- условия доставки, оплаты, обмена и возврата;
- статус заказа;
- применение бонусов и условий программы лояльности;
- подбор товара по заданным параметрам;
- передача обращения сотруднику;
- оформление заявки, заказа или резервирования.
Сначала для каждого направления определяют, каким результатом должен закончиться диалог.
Определим, какие обращения стоит передать чат-боту
Разберем основные вопросы клиентов и выделим сценарии, с которых целесообразно начать внедрение - https://sowita.kz/ai-business-kazakhstan
Например, ответить на вопрос об условиях возврата и проверить статус конкретного заказа - разные задачи. В первом случае достаточно утверждённого документа. Во втором потребуется идентификация клиента и обращение к системе, в которой хранится заказ.
Рабочая карта сценариев может выглядеть так:
Разбираются реальные обращения клиентов
Сценарии должны учитывать то, как люди действительно пишут компании. Для анализа используют обезличенные обращения из доступных каналов:
- чаты на сайте;
- переписки в мессенджерах;
- обращения из социальных сетей;
- заявки из CRM;
- сообщения службы поддержки;
- расшифровки разговоров, если компания уже анализирует звонки.
Обращения группируют по темам и смотрят, что делает сотрудник после получения вопроса. Иногда оператор сразу отправляет готовую инструкцию. Иногда проверяет данные в нескольких программах, уточняет информацию у магазина или передаёт запрос другому подразделению.
Так выявляется не только содержание будущих ответов, но и фактический маршрут обращения внутри компании.
На этом этапе важно найти:
- повторяющиеся вопросы;
- запросы, на которые сотрудники отвечают по-разному;
- темы с большим количеством уточнений;
- действия, требующие перехода в другую систему;
- ситуации, в которых сотрудник не может дать окончательный ответ;
- обращения, которые нельзя передавать чат-боту.
Такой разбор защищает проект от распространённой ошибки: компания автоматизирует ответы на вопросы, которые уже хорошо раскрыты на сайте, а основная нагрузка остаётся в запросах по заказам, остаткам, возвратам и исключительным ситуациям.
Проверяется, откуда компания берет правильный ответ
После анализа обращений составляют карту источников.
Один ответ может находиться на сайте, другой — в инструкции для сотрудников, третий — в 1С, CRM или системе лояльности. Часть информации сотрудники могут хранить в таблицах, переписках или личных заметках.
Источники разделяют на две группы.
Постоянная информация
К ней относятся сведения, которые меняются относительно редко:
- адреса и контакты;
- правила обслуживания;
- способы оплаты;
- условия доставки;
- порядок возврата;
- описание программ лояльности;
- инструкции по использованию товаров;
- ответы на организационные вопросы.
Такую информацию можно подключить к базе знаний чат-бота.
Изменяемые данные
К ним относятся:
- цены;
- остатки;
- статус заказа;
- состав и состояние корзины;
- начисленные бонусы;
- индивидуальные условия клиента;
- доступные интервалы доставки;
- данные по резервированию.
Эти сведения нельзя надёжно поддерживать копированием документов. Чат-бот должен получать их из рабочей системы в момент обращения.
На этом этапе также выявляются противоречия. Например, на сайте могут быть опубликованы одни условия, во внутренней инструкции — другие, а сотрудники применяют третью практику. Подключение чат-бота не решит такое расхождение: сначала бизнесу нужно определить действующее правило и ответственного за его обновление.
Готовится база знаний
Перед использованием материалы проверяют и приводят к структуре, по которой система сможет находить подходящие фрагменты.
Для этого:
- Удаляют устаревшие версии и дубли.
- Определяют основной источник для каждой темы.
- Разделяют большие документы на самостоятельные смысловые блоки.
- Добавляют признаки: подразделение, бренд, регион, язык, категория товара и период действия.
- Разграничивают публичные и внутренние материалы.
- Указывают владельца каждого документа.
- Устанавливают порядок обновления базы.
При ответе чат-бот сначала ищет подходящую информацию в подключённых материалах, а затем формирует ответ на её основе. В технической документации такой подход называется поиском с дополнением контекста: качество результата зависит не только от модели, но и от подготовки документов, разбиения материалов и настройки поиска.
Для розничной компании особенно важно учитывать различия между магазинами, регионами и форматами продаж. Условия интернет-магазина могут не совпадать с правилами покупки в торговой точке. Общая инструкция без таких признаков приведёт к тому, что бот найдёт формально похожий, но неприменимый ответ.
Если обслуживание ведётся на русском и казахском языках, материалы и тестовые вопросы готовят отдельно для каждого языка. Перевод ответа в момент диалога не заменяет проверенную базу знаний на нужном языке.
Проектируется диалог, а не только текст ответа
Правильная информация ещё не гарантирует, что клиент решит вопрос.
Чат-бот должен понимать, каких данных не хватает, последовательно их запросить и не заставлять человека повторять уже переданную информацию.
В сценарии заранее определяют:
- какие данные обязательны для ответа;
- в каком порядке задаются уточняющие вопросы;
- как бот реагирует на неполное или двусмысленное сообщение;
- в каких случаях он показывает ссылку на документ;
- когда предлагает связаться с сотрудником;
- что передаётся оператору вместе с диалогом;
- какие действия требуют подтверждения клиента;
- как сообщается об ошибке или недоступности системы.
Например, по сообщению «не пришёл заказ» нельзя сразу назвать причину. Сначала необходимо определить заказ и проверить его фактический статус. Если система недоступна, бот не должен создавать правдоподобное объяснение. Он сообщает, что проверка сейчас невозможна, и предлагает предусмотренный компанией вариант продолжения.
Отдельно проектируется передача сотруднику. Оператору нужны не только последние слова клиента, но и уже собранные данные: тема обращения, номер заказа, выбранный магазин, выполненные проверки и причина передачи.
Без этого чат-бот не сокращает путь клиента, а добавляет ещё один этап перед разговором с человеком.
Чат-бота подключается к системам компании
База знаний позволяет отвечать на информационные вопросы. Для работы с заказами, товарами и клиентскими данными требуются интеграции.
В зависимости от задачи чат-бот может обращаться к:
- 1С или другой учётной системе;
- CRM;
- системе управления заказами;
- товарному каталогу;
- сервису доставки;
- программе лояльности;
- системе поддержки;
- сервису записи или бронирования;
- личному кабинету клиента.
Архитектура проекта в упрощённом виде выглядит так:
Сайт или мессенджер → обработка сообщения → база знаний и правила диалога → информационные системы → ответ клиенту или передача сотруднику
Все операции делят на чтение и изменение данных.
Получить статус заказа или проверить остаток — это чтение. Создать заказ, оформить резерв, изменить контактные данные или применить бонусы — изменение.
Для операций второго типа отдельно настраивают:
- идентификацию пользователя;
- проверку обязательных данных;
- права доступа;
- подтверждение действия;
- защиту от повторного выполнения;
- фиксацию результата;
- журнал операций.
Языковая модель может определить намерение клиента и подготовить параметры запроса, но проверка прав и выполнение критичных действий должны оставаться в программной логике. OWASP рекомендует не передавать модели контроль над авторизацией и другими обязательными ограничениями, а для действий с повышенным риском использовать минимальные права и подтверждение человека.
Собирается тестовый набор из реальных вопросов
Демонстрация, на которой бот отвечает на несколько заранее подготовленных вопросов, не показывает его готовность к работе.
Для проверки создают отдельный набор обращений. Основой становятся реальные обезличенные сообщения клиентов, включая неудобные формулировки:
- опечатки и сокращения;
- сообщения без контекста;
- несколько вопросов в одной фразе;
- разговорные названия товаров;
- противоречивые данные;
- повторные обращения;
- просьбы выполнить недоступное действие;
- вопросы, для которых в базе нет ответа;
- попытки получить закрытую информацию.
Для каждого теста фиксируют:
- ожидаемый смысл ответа;
- источник, который должен использовать бот;
- необходимые уточнения;
- требуемое действие в системе;
- условие передачи сотруднику;
- недопустимые варианты ответа.
Проверяется не красота формулировки, а результат:
- Найдена ли подходящая информация.
- Соответствует ли ответ источнику.
- Не добавлены ли неподтверждённые сведения.
- Заданы ли необходимые уточнения.
- Выполнено ли действие в системе.
- Правильно ли определена необходимость оператора.
- Не раскрыты ли данные, к которым у пользователя нет доступа.
- Укладываются ли время ответа и стоимость обработки в требования проекта.
Систематическое тестирование необходимо проводить не только перед запуском, но и после изменения документов, инструкций, интеграций и используемой модели. Для подобных систем применяются отдельные наборы проверочных запросов и автоматические либо экспертные оценки результатов.
Определяются правила работы с персональными данными
Чат-бот розничной компании может получать имя, номер телефона, данные заказа, историю обращений и сведения программы лояльности. До разработки необходимо определить, какие данные действительно нужны для каждого сценария.
Не следует передавать модели всю карточку клиента, если для ответа достаточно номера и статуса заказа.
В проекте предусматривают:
- минимальный состав передаваемых данных;
- маскирование информации в журналах;
- разграничение доступа;
- сроки хранения переписок;
- удаление или обезличивание данных;
- отдельное хранение ключей и паролей;
- защиту закрытой базы знаний;
- регистрацию обращений к информационным системам.
Для компаний, работающих в Казахстане, сбор, обработка и защита персональных данных должны быть организованы в соответствии с законодательством Республики Казахстан. Закон предусматривает требования к цели обработки, согласию субъекта и защите данных, а действующие правила требуют определить бизнес-процессы, в которых используются персональные данные, и применять правовые, организационные и технические меры защиты. Конкретную схему обработки следует согласовать с юристом и специалистом по информационной безопасности.
Также проверяется устойчивость чат-бота к сообщениям, которые пытаются изменить его правила: например, заставить игнорировать ограничения, показать внутренние инструкции или получить чужие данные. Такие запросы относятся к рискам внедрения приложений на основе языковых моделей, поэтому одних текстовых запретов внутри инструкции недостаточно. Необходимы внешние проверки, ограничения доступа и контроль выполняемых действий.
Запускается ограниченный пилот
Первый запуск не должен охватывать все обращения, каналы и подразделения компании.
Для пилота выбирают контролируемый контур, например:
- один канал;
- несколько типов обращений;
- отдельную товарную категорию;
- часть магазинов;
- информационные ответы без изменения данных;
- работу только в часы присутствия операторов.
На реальных обращениях оценивают:
- долю вопросов, решённых без сотрудника;
- правильность ответов;
- количество ошибочных и лишних переводов;
- успешность действий в системах;
- повторные обращения по той же теме;
- время сотрудника после передачи диалога;
- причины, по которым бот не смог помочь;
- стоимость обработки диалогов.
Команда получает перечень конкретных проблем: не хватает документа, плохо определяется товар, система слишком долго возвращает остатки, пользователи не проходят идентификацию или сценарий требует слишком много уточнений.
После исправлений повторяют тестирование и только затем расширяют контур.
После запуска начинается сопровождение
Информация о товарах, доставке, возвратах и программах лояльности меняется. Появляются новые формулировки вопросов, меняются внешние сервисы и внутренние процессы.
Поэтому для чат-бота назначают владельцев:
- бизнес отвечает за правила и содержание;
- сотрудники поддержки отмечают проблемные диалоги;
- ИТ-команда контролирует интеграции и доступность;
- команда проекта анализирует ответы и обновляет тесты;
- информационная безопасность проверяет доступы и журналы.
В рабочем режиме отслеживают:
- вопросы без найденного ответа;
- ответы с неподходящим источником;
- рост переводов на сотрудников;
- ошибки интеграций;
- действия, которые не были завершены;
- обращения по новым темам;
- изменение времени и стоимости обработки;
- попытки получить закрытые данные.
Изменение одного документа может повлиять сразу на несколько сценариев. Поэтому обновление базы знаний должно сопровождаться повторной проверкой связанных вопросов.
Что получает бизнес после внедрения
Результат проекта — не только окно чата.
В состав работающего решения входят:
- согласованный перечень задач и ограничений;
- карта клиентских обращений;
- подготовленная база знаний;
- правила обновления информации;
- сценарии уточнений и передачи сотруднику;
- интеграции с рабочими системами;
- настроенные права и проверки;
- тестовый набор;
- журналирование действий;
- аналитика обращений;
- инструкции для сотрудников;
- порядок сопровождения и развития системы.
Именно эти элементы определяют, сможет ли компания использовать чат-бота после демонстрации и управлять качеством его работы.
От чего зависит стоимость внедрения ИИ-чат бота
На объём проекта влияют:
- число каналов;
- количество языков;
- состав сценариев;
- качество исходных документов;
- количество информационных систем;
- наличие готовых API;
- необходимость идентификации клиента;
- выполнение операций с данными;
- требования к безопасности;
- нагрузка и требуемая скорость ответа;
- интерфейс для сотрудников;
- аналитика и отчётность;
- условия сопровождения.
Бот, который отвечает по утверждённым материалам, и система, которая проверяет остатки, оформляет резерв и изменяет заказ, — разные по составу проекты, даже если для клиента оба решения выглядят как одно окно переписки.
Когда чат-бот не нужен
Иногда задачу можно решить без разработки ИИ-чат-бота.
Например, если обращений немного, вопросы не меняются и клиенту достаточно выбрать один из нескольких вариантов, может подойти обычная форма, меню или сценарный бот.
Не стоит начинать внедрение, если:
- компания не определила действующие правила;
- в системах нет достоверных данных;
- сотрудники используют разные источники;
- никто не отвечает за обновление документов;
- процесс постоянно меняется;
- нет возможности безопасно предоставить доступ к информации;
- компания ожидает, что чат-бот самостоятельно исправит проблемы клиентского сервиса.
В таких условиях проект сначала обнаружит организационные расхождения, а уже затем сможет перейти к автоматизации.
С чего начать проект
Для первичной оценки полезно подготовить:
- обезличенную выборку обращений клиентов;
- перечень каналов коммуникации;
- список основных тем;
- документы, по которым работают сотрудники;
- перечень систем с данными о товарах, заказах и клиентах;
- список действий, которые планируется передать чат-боту;
- правила, по которым обращение передаётся человеку.
По этим материалам можно определить первый контур, состав интеграций и вопросы, которые необходимо решить до разработки.
Грамотно внедрённый чат-бот не пытается заменить всю клиентскую службу. Он берёт ограниченный участок процесса, работает с проверенными источниками, выполняет разрешённые действия и передаёт сотруднику всё, что не может обработать надёжно.
Запишитесь на диалог с экпертами SOWITA - мы бесплатно оценим объем работ и дадим предварительную оценку проекта - https://sowita.kz/ai-business-kazakhstan
