ИИ агент заказы превращает сообщения из почты, формы и мессенджера в проверенные черновики учётной системы. Он уточняет позиции, сверяет наличие и условия клиента, а сотрудник подтверждает итог перед отправкой или проведением. Такой сценарий особенно полезен там, где один и тот же заказ приходит в разных форматах и легко теряется между каналами.
Путь заказа
Агент заказов извлекает позиции из нескольких каналов, сверяет каталог и условия, создаёт черновик; подтверждение остаётся за сотрудником.
Проследите путь заявки от входящего сообщения до документа в учётной системе. Канал сообщает текст и вложения, агент выделяет клиента, позиции, количества и срок, затем сопоставляет найденное со справочниками. На каждом этапе сохраняйте исходный фрагмент. Если покупатель написал «два ящика» без единицы товара в каталоге, система должна попросить уточнение, без догадки о штуках. Неполная заявка остаётся в очереди разбора с указанием причины.
Многоканальность создаёт отдельную проблему дублей: клиент отправил письмо и повторил заказ в чате. Сравнивайте идентификатор клиента, состав, время и внешний номер, но окончательное совпадение для сомнительного случая утверждает оператор. Агент для заявок в 1С показывает общий механизм действий в базе. Аналитика продаж на маркетплейсах касается итоговых чисел, тогда как здесь важен каждый конкретный заказ и его статус. Разведите эти задачи в описании проекта, чтобы мониторинг показателей оставался отдельной задачей.
В маршруте заявки отделите коммерческие обещания от фактов учётной системы. Клиент может попросить скидку, которой нет в договоре, или ускоренную доставку без доступного окна. Агент фиксирует запрос и направляет его менеджеру. Такое разделение защищает команду от ситуации, когда черновик выглядит как уже согласованное обязательство.
Извлечение позиций
Начните с ограниченного перечня полей: отправитель, товар, количество, адрес доставки и желаемый срок. Модель извлекает их в структурированный объект и рядом показывает цитату из сообщения. Затем отдельный код проверяет обязательность полей, формат и соответствие каталогу. Название товара из письма может отличаться от номенклатуры в 1С, поэтому храните таблицу подтверждённых соответствий. Новые совпадения с низкой уверенностью передавайте сотруднику.
Поддержите вложения только после проверки качества текста: скан с распознаванием может перепутать артикул и количество. Для подозрительной строки оператор видит исходное изображение и распознанный фрагмент. GigaChat или YandexGPT помогают разбирать русскоязычные письма; точные названия моделей и тарифы сверяйте в документации вендора. Для составления запроса полезно описать допустимые поля, примеры отказа от догадки и формат ответа. Так агент выдаёт проверяемые данные, без убедительного пересказа обращения.
- Примите сообщение и сохраните исходник.
- Извлеките позиции с цитатами и проверьте обязательные поля.
- Сверьте каталог, остатки и условия.
- Создайте черновик и отправьте его оператору.
Сохраняйте исходный язык покупателя рядом с нормализованным названием товара. Иначе оператор увидит готовый артикул и потеряет возможность проверить, правильно ли система поняла фразу. Если номенклатура меняется, повторная проверка старых соответствий выявит устаревшие пары. Отдельный список спорных названий поможет владельцу каталога улучшить справочник.
Проверка условий
Наличие, цена и условия доставки должны приходить из действующих систем, без догадок модели. На момент проверки фиксируйте время остатков и версию прайса. Если товар в резерве или клиенту положены особые условия, эти правила проверяет код по подтверждённому источнику. Модель может указать, какие сведения запросить, но расчёт суммы и доступного количества выполняйте отдельной процедурой. Неоднозначность возвращается менеджеру с конкретным вопросом.
Условный заказ содержит товар, который числится на двух складах, а клиент просит доставку завтра. Агент показывает остатки по складам и доступные окна, а обещание срока оставляет менеджеру. Менеджер выбирает вариант и сообщает клиенту подтверждённые условия. Автоматизация бизнес процессов помогает описать маршрут и контрольные точки. Если заказ относится к дистрибуции с собственными правилами маршрутов и скидок, полезен отраслевой материал об автоматизации заказов дистрибьютора. Здесь схема остаётся общей для нескольких каналов.
Когда остатки приходят из разных складов, проверьте резерв и доступность доставки по конкретному адресу. Сумма физических остатков сама по себе может вводить в заблуждение. В черновике показывайте источник каждого условия и момент его чтения. Если после согласования остаток изменился, сотрудник должен получить сигнал перед окончательным подтверждением.
Для разных категорий клиентов держите разные правила проверки условий. Корпоративный договор, розничная покупка и повторный заказ могут обращаться к разным источникам цены и доставки. Если категория клиента определена ошибочно, черновик отправляется на уточнение до расчёта. Это ограничивает влияние ошибки извлечения на коммерческое предложение.
Ограничьте первый поток одним каналом и известным каталогом. Ручные исправления черновиков покажут, какие правила следует уточнить.
Черновик и согласование
После проверки создайте в 1С или CRM черновик, связанный с исходным сообщением. Черновик содержит извлечённые позиции, найденные артикулы, результат сверки наличия и список открытых вопросов. До подтверждения сотрудником черновик остаётся без проведения: счёт, отгрузку и уведомление клиенту запускают после проверки. Оператор видит, почему агент выбрал конкретную номенклатуру и где потребовалось уточнение. Исправление сотрудника попадает в журнал и таблицу соответствий после проверки. Описать границы такого контура помогает страница об ИИ-агентах для бизнеса.
Для первого запуска возьмите один канал и типовой ассортимент. Измеряйте долю заявок с полными полями, долю верных соответствий каталогу и число черновиков, которые оператор вернул на исправление. Отдельно записывайте пропущенные дубли. При расширении на новые каналы пересматривайте формат входа, поскольку сообщение из формы и свободный текст письма требуют разных проверок. Ручное подтверждение остаётся рубежом ответственности. Отдельные правила для низкорисковых операций команда согласует позже.
Оператору нужна возможность исправить каждое поле черновика и увидеть последствия. Изменение артикула должно запускать повторную проверку остатков, изменение адреса — пересмотр доставки. Журнал сохраняет исходное предложение агента, правку человека и новый результат проверок. Так команда понимает, где ошиблась модель, а где поменялись обстоятельства заказа.
Покажите оператору итог вместе с причинами предупреждений. Значок «остаток требует сверки» должен открывать время последней загрузки, склад и запрос к источнику. Тогда сотрудник способен решить вопрос по существу, а команда разработки получает конкретный след для исправления интеграции.
Где теряются заказы в ваших каналах?
Журнал работы
Журнал объединяет источник сообщения, время получения, версию правил, ответы справочников, черновик и решение оператора. По нему можно восстановить путь каждого заказа и найти причину ошибки. Храните только необходимые данные и ограничивайте доступ по ролям. Если ответ каталога временно отсутствует, заявка ждёт повторной проверки, а сотрудник получает понятный статус. Повторный запуск по тому же внешнему номеру должен находить существующий черновик, без создания нового.
Разбирайте ошибки по группам: неверное извлечение, неточное сопоставление номенклатуры, устаревший остаток, сбой записи в систему. У каждой группы свой способ исправления. Если исправлять всё изменением промпта, пропустите сбой интеграции. Для проекта заранее назовите владельца каталога и ответственного за ручное согласование. Стоимость зависит от числа каналов, качества справочника и сложности правил; план работ удобнее обсуждать на примерах реальных обезличенных заказов. Это даст точную карту исключений до подключения агента к рабочему потоку.
При разборе ошибок сохраняйте небольшой набор обезличенных заявок для повторной проверки. В него включите письмо с несколькими позициями, дубль из другого канала и запись с отсутствующим товаром. После любой правки промпта или правила сверки прогоните эти случаи снова. Это защищает рабочий поток от незаметного ухудшения соседних сценариев.
Назначьте регулярный разбор спорных заказов вместе с владельцем каталога. Его решения пополнят проверенную таблицу соответствий и снизят число одинаковых ручных исправлений.