Кейс Acolyte Wear: ИИ-агент закрыл 55% из 11 000 диалогов

Клиент пишет в Telegram: «я сделал заказ, когда оформите его, мне никто так и не ответил». Через три минуты он знает номер заказа, статус, дату обработки и то, что посылка уедет СДЭКом. Менеджер в этот разговор не заходил.

Фиолетовым выделено то, чего клиент не видит: главный агент сходил к субагенту за правилами обработки заказов и параллельно нашёл заказ в CRM. Так это работает сейчас. Начинали с агента, который умел отвечать только по базе знаний.

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

Пилот вместо технического задания

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

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

В первый день агент научился говорить «не знаю»

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

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

Каталог: два подхода мимо, третий рабочий

Дальше товары. Тут мы честно потратили время на два тупика.

Сначала думали парсить сайт. Качество плавает: каждый сайт устроен по-своему, и универсальный сбор редко даёт аккуратный каталог.

Потом попробовали YML/XML-выгрузку. Сайт собран на Tilda, и в выгрузку сыпались позиции, которых в продаже давно нет.

Рабочий вариант оказался скучнее: брать данные оттуда, где товар появляется впервые. У Acolyte это «МойСклад». Ссылок на часть товаров там не хватало, клиент доработал карточки — и новые позиции поехали в каталог агента уже с нужными полями.

Остатки превратили справочную в продавца

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

И подключили остатки. Интеграция с API «МоегоСклада» заняла несколько часов, и после неё агент перестал быть справочной. Спрашивают «есть куртка M57?» — он смотрит каталог и остатки. Куртка последняя — аккуратно подсветит, что размер заканчивается. Куртки нет — предложит другой размер, другой цвет или близкую модель.

Дропы и комплекты собираются вручную

У бренда регулярно выходят дропы, новые коллекции и обновлённые линейки. Внутри бывают капсулы и комплекты: куртка и штаны продаются по отдельности, а вместе идут со скидкой. На сайте комплект видно, в «МоёмСкладе» это две разные позиции.

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

«Где мой заказ» — самый частый вопрос

Через месяц тестирования клиент вернулся с вопросом, что ещё умеет агент. Так появился поиск заказов в RetailCRM.

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

Сначала работал обычный коннектор: клиент пишет с известного номера, система сопоставляет номер с карточкой. Быстро выяснилось, что этого мало. Человек обращается впервые, и номера в CRM ещё нет. Или пишет из Telegram, где телефон в диалог не передаётся.

Тогда добавили MCP-сервер. Если идентификатора не видно, агент спрашивает телефон прямо в переписке, получает его и идёт с ним в RetailCRM. Тот же приём работает с любой другой CRM или внешней системой: через MCP-сервер агент получает ровно те данные, которые нужны для ответа, и ничего сверх.

Как это устроено внутри

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

Поиск заказов в RetailCRM висит прямо на главном агенте, без отдельного субагента. Так решили осознанно: при текущей нагрузке главный справляется сам, а лишний вызов — это лишние деньги на каждом диалоге.

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

Скриншот в начале статьи — как раз этот механизм в работе. А через сутки тот же клиент возвращается с вопросом о заказе: телефон и ФИО агент не переспрашивает, он их уже знает, поэтому сразу идёт в CRM за свежим статусом.

Что мы поняли про промпты

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

• Промпт должен быть сухим и коротким: только нужные правила, без воды и повторов.
• Разделы помогают: tone of voice, вызов инструментов, перевод на оператора, запреты, примеры диалогов.
• Ошибку нельзя закрывать костылём. Агент вернул не ту почту — причина где-то в базе знаний, структуре данных, модели, маршрутизации или качестве источника. Приписка «а вот эту почту не пиши» лечит симптом.

Так промпт и остался регламентом поведения, а не свалкой исключений под каждый найденный баг.

На «ты», но без «йоу, бро»

Аудитория у Acolyte молодая, и формальная служба поддержки звучала бы тут чужеродно. Агента настроили на «ты», дружелюбный тон и умеренный сленг.

Сначала он перестарался. В ответы пошли «йоу», «бро», «сорян» — примерно всё, что взрослый человек представляет себе под словом «молодёжный».

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

Каждый ответ при этом заканчивается строкой «Вам ответил наш ИИ-помощник». Притворяться человеком клиент не стал.

Цифры

Агент обработал больше 11 000 диалогов. 55% из них он закрыл полностью сам, остальные передал оператору.

Загрузка скачет от месяца к месяцу: влияют сезонность и выход коллекций. Тарификация в «Найми ИИ» считается по реально обработанным диалогам, поэтому в тихий месяц счёт меньше, а не «как в договоре». Данные — на 4 июня 2026 года.

Что происходит после запуска

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

На Новый год клиент прислал ведущему аналитику проекта лучший костюм из своей коллекции.

Собрать похожее

Первый контур этого кейса — агент по базе знаний с передачей менеджеру — собирается самостоятельно за день. Заведите агента на триале, загрузите материалы и погоняйте ответы до подключения боевого канала. Условия подписки — на странице «Тарифы», сценарий для магазина разобран в решении для e-commerce, а как подключается CRM — на странице интеграции с RetailCRM.