Электронная торговля · ИИ
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 опознают собеседника по-разному, а ответ и набор разрешённых действий обязаны быть одинаковыми. Иначе один покупатель получает два разных ответа в зависимости от того, где написал.
Как шла работа
- 01
Разбор обращений
Неделя 118 000 исторических обращений разобрали и разложили по типам запросов. На выходе получился не список тем для базы знаний, а список действий: что бот должен уметь найти и что — сделать. Оттуда же видно, какая часть очереди вообще не про правила магазина.
- 02
Интеграции
Недели 2–3API к CRM, заказам, платежам и логистике плюс таблица соответствий, которая сводит покупателя и заказ к одной записи. Две недели работы, и вся она до бота: без данных боту нечем отвечать, кроме справки.
- 03
База знаний и RAG
Неделя 4Инструкции и справка магазина разобраны на фрагменты и уложены в Qdrant. Модель получает их вместе с вопросом, а не хранит внутри: правка правила возврата отражается в ответах сразу, без переобучения и без релиза.
- 04
Бот и сценарии действий
Недели 5–6Здесь разошлись две разные вещи: ответ, который модель собирает из найденных данных, и действие, которое она только предлагает. Смена адреса, отмена и возврат пошли заранее описанными шагами и с подтверждением клиента.
- 05
Сайт, WhatsApp, Telegram
Неделя 7Три канала подключены к одному сервису: правила, сценарии и порог эскалации у них общие, разное только опознание собеседника и формат сообщения. Диалог из мессенджера попадает в ту же очередь helpdesk, что и диалог с сайта.
- 06
Пилот и эскалация
Неделя 8A/B-пилот: часть обращений шла через бота, часть — прежним путём. Настраивали не формулировки, а границу: в какой момент бот обязан отдать диалог человеку. Эта граница и решает, экономит автоматизация время или добавляет клиенту лишний круг.
Технические решения
Каждая часть закрывает свой участок и не лезет в соседний: NestJS ходит в чужие системы и выполняет сценарии, PostgreSQL хранит соответствия идентификаторов и историю диалогов, Qdrant отдаёт фрагменты базы знаний под конкретный вопрос.
Факты — по API, правила — через RAG
Ни одна цифра в ответе не берётся из модели. Статус заказа, движение посылки и платёж запрашиваются в момент вопроса, инструкции магазина приходят фрагментами из Qdrant. Разделение проведено по владельцу: и данные заказа, и правила магазина меняются на стороне заказчика, и внутрь модели не помещаются ни те ни другие.
Таблица соответствий вместо догадок
Первый шаг любого ответа про заказ — понять, чей он. Идентификаторы пяти систем лежат рядом в PostgreSQL, и бот сначала собирает из них покупателя, а уже потом спрашивает про заказ. Без этого шага он отвечал бы про чужой заказ так же уверенно, как про свой.
Действия — детерминированными сценариями
Модель распознаёт намерение и собирает данные, дальше идут описанные шаги: показать, что именно изменится, дождаться подтверждения клиента, выполнить, записать результат. Возврат, отмена и смена адреса не поручены генерации ни в одной точке.
Передача человеку вместе с контекстом
Если бот не закрыл вопрос, оператор получает в helpdesk не пустой диалог: переписку, найденный заказ, статус доставки и то, что бот успел проверить. Иначе автоматизация добавила бы покупателю круг ожидания, а оператору — ту же работу с начала.
Один сервис на три канала
Сайт, WhatsApp и Telegram — три входа в одно приложение на NestJS. Правила, сценарии и порог эскалации описаны один раз: правка доезжает во все три канала сразу, и обещание магазина не зависит от того, где покупатель его прочитал.
Что осталось за рамками
Часть работы сознательно осталась на стороне заказчика, часть лежит за границей первой линии.
Интерфейсы операторов. Мы отдавали диалог и контекст в существующий helpdesk, но экранов для сотрудников не делали и процесс второй линии не переписывали.
Вторая линия. Всё, что бот не закрывает, ведёт человек по правилам магазина: автоматизирована первая линия, а не поддержка целиком.
Содержание базы знаний. Его пишет и правит заказчик. На нас было то, чтобы правка доезжала до ответа без релиза, а не то, что в ней написано.
Правила возврата и обмена. Их устанавливает магазин, сценарии их исполняют. Поэтому смена правила остаётся правкой в базе знаний, а не задачей на разработку.
Сейчас в работе: граница эскалации. Её двигают по тем же данным, по которым CSAT автоматизированных диалогов вырос с 4,1 до 4,6 за два месяца после запуска, — настройка не кончилась вместе с восьмой неделей.
Другие проекты
Финтех
Tallim
Сверка платежей со счетами в финансовом отделе платёжной компании: строгие правила, похожесть и модель работают по очереди. Спорное подтверждает человек.
31 000 платежей
в месяц проходят сверку, до человека доходит 1,9%
Python · PostgreSQL · OpenAI API
Строительство
Prokta
Разбор тендерной документации для коммерческого отдела генподрядчика: на входе архив файлов, на выходе отчёт по условиям со ссылкой на страницу для каждого пункта.
91%
критичных условий из контрольной выборки система нашла сама
Python · Qdrant · OpenAI API
Контакты
Пришлите описание задачи
Ответ с объёмом работ, сроками и оценкой бюджета придёт в течение 24 часов.
Первый звонок — 30 минут, без обязательств с вашей стороны.