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

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

Такая система особенно полезна в заказном производстве, строительстве, логистике, дистрибуции и сложных B2B-услугах. В этих сферах менеджеру недостаточно выбрать позицию из каталога: нужно учесть конфигурацию продукта, объем работ, материалы, загрузку ресурсов, условия поставки и индивидуальные договоренности с заказчиком.

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

Что представляет собой ИИ для расчета стоимости заказа

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

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

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

Какие задачи можно передать системе

Система может охватывать путь от первого обращения до сохранения готового КП в CRM. Границы автоматизации зависят от сложности продукта и цены ошибки.

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

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

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

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

Как проходит расчет и подготовка коммерческого предложения

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

Сбор и нормализация требований

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

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

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

Применение расчетных правил

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

Формулы следует хранить вне языковой модели: в конфигураторе, ERP, CPQ-системе, расчетном сервисе или специализированном модуле. Это позволяет тестировать вычисления, управлять версиями правил и объяснять, из чего сложилась сумма. Если цена изменилась из-за нового тарифа на доставку, пользователь увидит конкретную причину, а не предположение модели.

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

Формирование и согласование КП

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

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

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

Из каких компонентов состоит корпоративное решение

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

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

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

Где автоматизация дает наибольший эффект

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

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

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

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

Какие данные нужно подготовить

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

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

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

Нужна и политика актуальности. Цена должна сопровождаться датой действия и источником, формула — номером версии, а шаблон КП — владельцем и датой утверждения. Без версионирования невозможно объяснить, почему два одинаковых заказа, рассчитанных в разное время, получили разные суммы.

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

Почему цену нельзя полностью поручать языковой модели

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

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

Практическое разделение ролей выглядит так:

• ИИ распознает, что клиент запросил срочное производство и доставку;
• бизнес-правило определяет, доступен ли срочный тариф для выбранной продукции;
• расчетный сервис применяет утвержденный коэффициент;
• ИИ объясняет клиенту, из чего состоит предложение;
• контрольный модуль проверяет итог, а ответственный сотрудник подтверждает исключение.

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

Как контролировать ошибки и качество результата

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

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

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

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

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

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

Как защитить данные клиентов и коммерческие условия

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

Для российских компаний обработка персональных данных должна быть спроектирована с учетом Федерального закона № 152-ФЗ. Если данные передаются иностранному поставщику, отдельно оценивается трансграничная передача: статья 12 закона предусматривает предварительное уведомление уполномоченного органа и другие условия, зависящие от страны и схемы обработки. Архитектуру и документы следует проверять с юристом применительно к конкретному процессу, а не считать выбор российского интерфейса достаточным подтверждением соответствия требованиям. Текст статьи 12 Федерального закона № 152-ФЗ

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

Отдельная угроза возникает при обработке входящих документов. В текст файла могут быть встроены инструкции, пытающиеся изменить поведение агента или получить доступ к закрытой информации. OWASP определяет prompt injection как атаку, при которой вредоносная инструкция во входных данных заставляет языковую модель отступить от заданного поведения. Поэтому содержимое клиентского документа нельзя считать доверенной командой, а доступ агента к CRM, почте и файловым хранилищам необходимо ограничивать. OWASP: Prompt Injection

Как внедрять систему без риска для продаж

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

Диагностика и проектирование

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

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

Пилот в режиме помощника

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

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

Промышленный запуск

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

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

Как оценить экономический результат

Эффект следует считать по всему циклу подготовки предложения, а не по скорости генерации текста. Если документ создается за минуту, но менеджер еще час проверяет номенклатуру и исправляет сумму, процесс не стал быстрее.

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

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

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

Когда готового сервиса недостаточно

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

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

Между коробочным продуктом и разработкой с нуля есть промежуточный вариант: корпоративный сервис поверх существующей CRM, ERP и расчетных модулей. В нем ИИ отвечает за прием заявки и диалог, а компания сохраняет действующую логику учета. Такой подход часто снижает объем изменений, но требует качественного API и согласованной модели данных.

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

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

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

ИИ имеет смысл подключать после того, как для выбранного процесса определены обязательные поля, мастер-системы и допустимые исключения. Тогда модель ускоряет работу с естественным языком, а не подменяет отсутствующий регламент. Формулы, права доступа и контроль остаются обычной инженерной частью решения.

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

Об авторе

Игорь М.

Chief Editor

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

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