Перейти к содержимому

Электронная торговля · ИИ

Onvela

Интернет-магазин косметики: первую линию поддержки держит ИИ-бот. Он не пересказывает FAQ, а находит заказ покупателя, смотрит доставку и платёж и отвечает по данным.

Роль
Бэкенд, интеграции, ИИ-бот
Срок
8 недель
Стек
NestJS · PostgreSQL · Qdrant

Что изменилось

58%
обращений закрываются без участия оператора: бот находит данные, отвечает и, где нужно, выполняет действие.
27 минут → 18 секунд
до первого содержательного ответа. Двадцать семь минут — это то, сколько ждали в часы пик.
−41%
нагрузки на первую линию поддержки.
4,1 → 4,6
CSAT автоматизированных диалогов по пятибалльной шкале. Оценка выросла не на запуске, а за два месяца правок после него.

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

Что было до

Поддержка разбирала около 90 000 сообщений в месяц, и почти две трети из них были одним и тем же вопросом, только разными словами: где заказ, можно ли поменять адрес, отправили ли деньги за возврат. Чтобы ответить про один заказ, оператор открывал до шести систем — каталог, CRM, OMS, лояльность, кабинет службы доставки и сам helpdesk. В часы пик ожидание первого ответа доходило до 27 минут.

  • Около 90 000 сообщений в месяц приходило на первую линию. Каждое из них кто-то читал и на каждое кто-то отвечал руками.
  • 64% — повторяющиеся вопросы: те же формулировки, тот же путь по системам, разные заказы. Две трети очереди состояли из работы, которую уже делали вчера.
  • До 27 минут доходило среднее время первого ответа в часы пик. Столько ждал покупатель, у которого не приехала посылка, чтобы узнать, где она.
  • До шести систем открывал оператор ради одного ответа про заказ, доставку или возврат. Ответ был не сложным, он был долгим.

Что сделали

  • Факты по API, правила через RAG: статус заказа, движение посылки и платёж бот запрашивает в момент вопроса, а инструкции магазина получает фрагментами из базы знаний.

  • Один покупатель вместо пяти записей: идентификаторы каталога, CRM, OMS, лояльности и служб доставки сведены в таблицу соответствий — с неё начинается любой ответ про заказ.

  • Действия отделены от ответов: возврат, отмена и смена адреса идут детерминированными сценариями с подтверждением клиента, а не формулировкой модели.

Результат

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

Кто заказчик

Интернет-магазин косметики и товаров для ухода: собственный склад, своя программа лояльности, доставка внешними службами. Масштаб проще всего увидеть по поддержке — около 90 000 сообщений в месяц.

Вопрос покупателя почти всегда про конкретный заказ, а ответ на такой вопрос не лежит в одном месте: позиция — в каталоге, сам заказ — в OMS, история покупателя — в CRM, движение посылки — у перевозчика, и того же покупателя под своим номером знает программа лояльности.

Задача

Как ставил заказчик
«Сделайте AI-бота, который отвечает по базе знаний»: загрузить в него справку магазина и снять с операторов вопросы про доставку, оплату и условия возврата.
Как задача выглядела после разбора
Ответы по базе знаний закрывали небольшую часть нагрузки. Покупатели спрашивали не про правила, а про свой заказ: «Почему он до сих пор не приехал?», «Можно изменить адрес?», «Деньги за возврат уже отправили?». Чтобы ответить, мало понять текст: нужно узнать, кто пишет, найти его заказ, проверить статус в службе доставки, посмотреть платёж и определить, что разрешают правила магазина. Так бот по FAQ стал ИИ-оператором первой линии.

Почему нельзя было в лоб

Ни одного из этих условий проект не создавал. Каталог, CRM, OMS, программа лояльности и службы доставки уже стояли, правила магазина уже менялись, операторы уже работали в своём helpdesk. Каждое условие видно в архитектуре.

Пять систем, пять идентификаторов
Каталог, CRM, OMS, программа лояльности и службы доставки называют покупателя и заказ по-своему. Пока идентификаторы не сведены, у вопроса «где мой заказ» нет адресата: неизвестно, чей это заказ и который из них.
Правила возврата меняются
Их правят регулярно, и выученное устаревает молча: модель отвечает уверенно и неверно, а узнают об этом по жалобе. Поэтому в модель не попало ни одного правила магазина — они приходят к ней в момент вопроса, из базы знаний.
Факты живут снаружи и стареют сами
Статус заказа, движение посылки и состояние платежа лежат в чужих системах и меняются там, без нашего ведома. Их нельзя ни выучить, ни закэшировать надолго — только спросить по API в момент вопроса.
Деньги и изменения заказа
Возврат, отмена и смена адреса — не ответы, а действия. Неудачную формулировку правит следующая реплика, ошибочный возврат не правит ничто. Значит, эти шаги нельзя оставлять на усмотрение модели.
CRM и helpdesk не наши
Заменять их никто не планировал: там очередь, там история обращений, там привыкли работать операторы. Бот встраивался в чужой процесс — и отдавать диалог человеку должен был внутри него, а не рядом.
Три входа в один диалог
Сайт, WhatsApp и Telegram опознают собеседника по-разному, а ответ и набор разрешённых действий обязаны быть одинаковыми. Иначе один покупатель получает два разных ответа в зависимости от того, где написал.

Как шла работа

  1. 01

    Разбор обращений

    Неделя 1

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

  2. 02

    Интеграции

    Недели 2–3

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

  3. 03

    База знаний и RAG

    Неделя 4

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

  4. 04

    Бот и сценарии действий

    Недели 5–6

    Здесь разошлись две разные вещи: ответ, который модель собирает из найденных данных, и действие, которое она только предлагает. Смена адреса, отмена и возврат пошли заранее описанными шагами и с подтверждением клиента.

  5. 05

    Сайт, WhatsApp, Telegram

    Неделя 7

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

  6. 06

    Пилот и эскалация

    Неделя 8

    A/B-пилот: часть обращений шла через бота, часть — прежним путём. Настраивали не формулировки, а границу: в какой момент бот обязан отдать диалог человеку. Эта граница и решает, экономит автоматизация время или добавляет клиенту лишний круг.

Технические решения

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

  • Факты — по API, правила — через RAG

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

  • Таблица соответствий вместо догадок

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

  • Действия — детерминированными сценариями

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

  • Передача человеку вместе с контекстом

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

  • Один сервис на три канала

    Сайт, WhatsApp и Telegram — три входа в одно приложение на NestJS. Правила, сценарии и порог эскалации описаны один раз: правка доезжает во все три канала сразу, и обещание магазина не зависит от того, где покупатель его прочитал.

Что осталось за рамками

Часть работы сознательно осталась на стороне заказчика, часть лежит за границей первой линии.

  • Интерфейсы операторов. Мы отдавали диалог и контекст в существующий helpdesk, но экранов для сотрудников не делали и процесс второй линии не переписывали.

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

  • Содержание базы знаний. Его пишет и правит заказчик. На нас было то, чтобы правка доезжала до ответа без релиза, а не то, что в ней написано.

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

Сейчас в работе: граница эскалации. Её двигают по тем же данным, по которым CSAT автоматизированных диалогов вырос с 4,1 до 4,6 за два месяца после запуска, — настройка не кончилась вместе с восьмой неделей.

Контакты

Пришлите описание задачи

Ответ с объёмом работ, сроками и оценкой бюджета придёт в течение 24 часов.

Первый звонок — 30 минут, без обязательств с вашей стороны.