Что произошло в японской микрокомпании

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

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

Это полезный, но не лабораторный результат. Компания в публикации не названа, а G7 и OECD не приводят объём выборки, исходное время цикла, абсолютную выручку, стоимость разработки или долю ошибок. Поэтому формулировки о росте и экономии следует считать сообщением участника кейса, а не универсальным ориентиром ROI.

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

Как выглядит процесс без автоматизации

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

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

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

Архитектура, которую можно повторить

Практический контур для такого кейса состоит из семи слоёв.

1. **Единый вход.** Письма, форма сайта и сообщения поступают в одну очередь. Система сохраняет исходный текст, вложения, канал, отправителя и время.
2. **Разбор запроса.** Модель извлекает язык, компанию, товар, количество, географию, срок и недостающие поля. Результат записывается в строгую схему, а не остаётся свободным текстом.
3. **Проверка клиента и товара.** Детерминированный код сопоставляет контрагента с CRM, товар — с каталогом, а остатки и цены — с ERP. Если совпадение неоднозначно, агент не угадывает, а задаёт вопрос.
4. **RAG по разрешённым данным.** Поиск возвращает карточки товара, правила экспорта, шаблоны ответов и согласованные условия клиента. В ответ передаются ссылки на версии документов.
5. **Многоязычный черновик.** Модель формирует ответ на языке покупателя и параллельно показывает сотруднику русскую версию, использованные данные и поля, которые требуют подтверждения.
6. **Человеческие ворота.** Менеджер утверждает цену, скидку, срок, банковские реквизиты, договорные исключения и замену товара. Только после подтверждения отдельный сервис отправляет сообщение или создаёт документ.
7. **Журнал и обратная связь.** Сохраняются исходный запрос, найденные источники, версия модели, предложение, исправления сотрудника, выполненное действие и время каждого этапа.

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

Какие данные и интеграции нужны

Минимальный набор данных включает:

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

Интеграции лучше разделить на чтение и действие. Агент может читать каталог и статус заказа с сервисной учётной записью, но запись скидки или отправка счёта должна проходить через отдельный контролируемый метод. Для вложений нужен антивирус, ограничение типов файлов и изолированный парсер: письмо клиента нельзя считать доверенной инструкцией для системы.

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

Где уместен локальный контур

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

Для небольшого потока не обязательно сразу покупать GPU. Пилот можно провести на арендуемом защищённом сервере или уже имеющемся оборудовании, замерив задержку и стоимость. Локальность не отменяет разграничение доступа, резервное копирование, журналирование и проверку качества перевода.

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

Риски и ограничения

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

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

Третий риск — инструкция во вложении или письме, пытающаяся изменить поведение агента. Контент клиента рассматривается как данные. Системные правила, перечень инструментов и права доступа задаются отдельно; ответы модели не исполняются как команды.

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

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

Как посчитать пилот без выдуманного ROI

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

Модельный пример: 600 запросов в месяц требуют в среднем 15 минут координации. Это 150 часов. Если AI-контур сокращает активную работу до 7 минут, но 20% запросов требуют дополнительных пяти минут проверки, трудозатраты становятся 80 часами. Потенциальное высвобождение — 70 часов в месяц.

Это не результат компании из G7, а иллюстрация с допущениями. Из стоимости 70 часов нужно вычесть инфраструктуру, поддержку, контроль качества и амортизацию интеграции. Затем отдельно учесть цену одной существенной ошибки и вероятность её появления. Если один неверный счёт способен съесть месячную экономию, автоматическая отправка счёта не входит в пилот.

Для оценки установите ворота:

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

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

План пилота на четыре недели

**Неделя 1.** Выберите один канал и один товарный сегмент. Опишите путь от запроса до счёта, измерьте базовое время и соберите 100–200 обезличенных примеров.

**Неделя 2.** Подключите чтение каталога и CRM. Агент только извлекает поля и готовит двуязычный черновик, ничего не отправляет.

**Неделя 3.** Запустите теневой режим на реальном потоке. Менеджеры сравнивают черновик со своим ответом, отмечают ошибки и причины правок.

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

Масштабировать стоит не «агента вообще», а конкретный участок, прошедший ворота. Следующим этапом может стать создание черновика счёта или задачи на отгрузку, но каждое новое действие получает отдельные права, тесты и владельца.

Что взять руководителю

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

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