От письма и Excel до черновика заказа в 1С: как ИИ автоматизирует B2B-заказы

Автоматизация B2B-заказов с ИИ превращает письмо, таблицу Excel, PDF или сообщение клиента в структурированный черновик документа в 1С. Система извлекает реквизиты и товарные позиции, сопоставляет их со справочниками, проверяет цены и остатки, а неоднозначные строки передает менеджеру.

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

Технически ИИ не заменяет 1С. Учетная система остается источником номенклатуры, цен, остатков, контрагентов и документов, а интеллектуальный модуль работает как промежуточный слой между каналами обращения и корпоративным контуром. Эффект зависит не столько от выбранной языковой модели, сколько от качества справочников, правил сопоставления и архитектуры контроля.

Почему ручная обработка B2B-заказов становится узким местом

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

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

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

Из каких этапов состоит автоматическая обработка заказа

Рабочий сценарий включает несколько разных технологий. Языковая модель понимает свободный текст, OCR распознает сканы и изображения, алгоритм поиска сопоставляет позиции со справочником, а интеграционный слой получает данные из 1С и создает документ. Называть всю цепочку «нейросетью» удобно, но для проектирования такое упрощение вредно.

Прием и классификация обращения

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

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

Извлечение данных из письма, Excel, PDF и изображений

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

Извлечение еще не означает, что товар найден. Строка «шайба увеличенная, 200 шт.» формально распознана правильно, но в ней может не хватать диаметра, материала или покрытия. Система должна фиксировать неполноту, а не угадывать значение по соседним строкам.

Сопоставление со справочником 1С

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

Для одной входящей строки возможны три результата:

• найдено однозначное соответствие;
• найдено несколько кандидатов;
• подходящей позиции нет.

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

Проверка коммерческих условий

Номенклатура отвечает на вопрос «что заказали», но не определяет, на каких условиях товар можно продать. Цена зависит от договора, типа цен, объема, склада, валюты и индивидуальных условий. Остаток также требует контекста: товар может числиться на складе, но быть зарезервирован под другой заказ.

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

Создание черновика в 1С

После проверок система создает непроведенный документ — например, «Заказ клиента» или «Заказ покупателя», в зависимости от конфигурации. В нем заполняются контрагент, организация, склад, позиции, количества и другие разрешенные поля. Менеджер получает уведомление, открывает документ, проверяет исключения и только затем подтверждает дальнейшее действие.

Платформа 1С поддерживает интеграцию через OData, HTTP- и web-сервисы. Для адаптации типовых решений также используются расширения: они позволяют добавлять функциональность, не изменяя основную конфигурацию и не снимая ее с поддержки. Конкретный способ подключения выбирают после проверки версии, конфигурации, существующих доработок и нагрузки на базу. Это подтверждается официальной документацией 1С по интеграционным механизмам и расширениям конфигураций.

Чем ИИ-агент отличается от импорта и чат-помощника

Импорт, ассистент и ИИ-агент решают разные классы задач. Выбор самого сложного варианта без необходимости увеличивает стоимость и число точек отказа.

ИИ-агент — это не чат с доступом к 1С, а управляемый исполнитель сценария. Он реагирует на событие, обращается к разрешенным источникам, выполняет последовательность проверок и передает результат следующему участнику процесса. Чат может быть одним из интерфейсов агента, но сам по себе не обеспечивает ни интеграцию, ни контроль действий.

Где должен оставаться человек

Безопасная модель для B2B-заказов строится вокруг черновика и очереди исключений. ИИ может предложить соответствие, но не должен скрывать неопределенность. Если в заявке указано «М8», а в каталоге есть несколько классов прочности и покрытий, менеджер обязан увидеть развилку до формирования отгрузки.

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

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

Какие ошибки нельзя решить одной нейросетью

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

Вторая группа рисков связана с контекстом продаж. Клиент может использовать старый артикул, попросить «как в прошлый раз» или указать цену из предыдущей спецификации. Для корректного решения нужны история заказов, договорные условия и правила доступа, а не только текст текущего письма.

Третья группа — технические сбои. Почта может доставить сообщение повторно, 1С может быть недоступна, а обмен — оборваться после создания документа. Архитектура должна защищать процесс от дублей, повторять безопасные операции и не создавать второй заказ при восстановлении соединения.

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

Как измерять эффект автоматизации

Оценивать проект по скорости ответа нейросети недостаточно. Бизнесу важно время от получения заявки до проверенного черновика, а не продолжительность отдельного API-запроса.

До пилота фиксируют несколько показателей:

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

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

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

С чего начинать внедрение

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

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

Перед разработкой необходимо зафиксировать:

1. Какие форматы и каналы входят в пилот.
2. Какие поля система извлекает и какие справочники использует.
3. При каких условиях позиция считается однозначной.
4. Какие действия разрешены автоматически.
5. Кто обрабатывает исключения.
6. Какие метрики определяют приемку.
7. Где размещаются данные и как ведется журнал доступа.

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

Архитектура, безопасность и размещение решения

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

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

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

Как перейти от пилота к рабочему контуру

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

Полигант может спроектировать такой контур под конкретный B2B-процесс: связать корпоративную почту, CRM, интеграционный слой и 1С; настроить извлечение данных, сопоставление номенклатуры, рабочее место для исключений и мониторинг. Для крупной компании ценность такой разработки состоит в адаптации к ее справочникам, правам и правилам продаж, а не в установке универсального «бота для заказов».

Рациональная первая задача — получить проверяемый черновик из одного повторяемого потока заявок. Когда качество подтверждено на реальных заказах, систему можно расширять до подготовки коммерческого предложения, проверки доступности, маршрутизации согласований и сопровождения заказа. Автоматизировать проведение и отгрузку имеет смысл только после того, как предыдущие этапы стали прозрачными и управляемыми.

Об авторе

Игорь М.

Chief Editor

Игорь М. — Chief Editor в компании Полигант, отвечает за редакционную стратегию и качество публикуемого контента. Работает в сфере цифровых финансов, блокчейн-технологий и ИИ более 6 лет.

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