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