Implementation scenario / 04 / Proposal automation
Подготовка коммерческих предложений с ценовыми ограничениями
КП собираются из старых файлов, содержат неактуальные условия и требуют ручной проверки каждой позиции.
Система формирует черновик по шаблону, каталогу и правилам скидок, а отклонения отправляет на согласование. Финальное решение и работа с исключениями остаются у ответственного: Ответственный подтверждает цену, юридические условия и обещания клиенту.
Проверить применимость сценария →
Problem / buying moment
Почему этот процесс становится задачей для руководителя.
Обычно к сценарию «Подготовка коммерческих предложений с ценовыми ограничениями» приходит коммерческий директор, руководитель продаж или собственник, когда воронка формально заполнена, но выручка всё ещё зависит от личного контроля руководителя. В этот момент локальная ручная проверка уже не масштабируется, но покупка отдельного AI-инструмента ещё не гарантирует изменения процесса.
В продажах ценность создаёт не ещё один отчёт, а своевременное действие: назначить ответственного, вернуть лид, зафиксировать следующий шаг или остановить ошибочное обещание.
ПОЗИЦИЯ IT WHITEРезультат этого сценария — не «внедрённый AI», а управляемое изменение показателей: время подготовки КП, ошибки в условиях, доля согласований без возврата. Система должна обнаруживать событие, объяснять контекст и доводить его до ответственного действия.
Target operating model
Что именно меняется после внедрения.
Как разобрать именно этот сценарий.
Здесь автоматизация оправдана только как часть рабочего маршрута. Исходная ситуация формулируется так: КП собираются из старых файлов, содержат неактуальные условия и требуют ручной проверки каждой позиции. Для коммерческий директор, руководитель продаж или собственник это уже не локальное неудобство сотрудника, потому что сбой отражается на показателе «время подготовки КП» и со временем становится нормой, которую команда перестаёт замечать. До проектирования мы берём несколько реальных событий, восстанавливаем последовательность действий и отделяем причину от симптома.
Контур данных начинается не с единого хранилища, а с минимального набора доказательств. CRM фиксирует первичное событие; ERP или 1С даёт контекст или состояние работы; шаблоны документов подтверждает следующий шаг и результат. Для каждого поля определяется источник, допустимая задержка и правило отсутствующего значения. Если событие нельзя восстановить, его нельзя безопасно использовать для автоматического решения.
Рабочая логика сценария выглядит конкретно: Система формирует черновик по шаблону, каталогу и правилам скидок, а отклонения отправляет на согласование. При этом система не подменяет владельца процесса. Ответственный подтверждает цену, юридические условия и обещания клиенту. Такое разделение нужно зафиксировать в интерфейсе, правах доступа и журнале действий, иначе формальный human-in-the-loop останется надписью в презентации, а человек будет подтверждать решение без достаточного контекста.
Главный негативный сценарий тоже проектируется заранее: Генеративная модель не должна придумывать наличие, сроки или скидки вне источника данных. Поэтому у пилота должны быть порог уверенности, маршрут исключения, возможность открыть первичные данные и понятный способ отменить действие. Ошибку нельзя прятать в среднем показателе: команда отдельно разбирает ложные срабатывания, пропущенные события и ситуации, где правило сработало правильно, но не привело к действию.
Руководитель принимает решение о масштабировании по трём наблюдаемым изменениям: «время подготовки КП», «ошибки в условиях» и «доля согласований без возврата». Сначала фиксируется базовая линия, затем одна зона работает в режиме пилота, а сравнение проводится на сопоставимом потоке. Целевой бизнес-результат: время подготовки КП, ошибки в условиях, доля согласований без возврата. Если изменение держится только благодаря ручному контролю разработчика, система ещё не готова к эксплуатации.
Architecture
AI не получает власть над процессом. Он получает ограниченную роль.
- CRM
- ERP или 1С
- шаблоны документов
Ответственный подтверждает цену, юридические условия и обещания клиенту.
Генеративная модель не должна придумывать наличие, сроки или скидки вне источника данных.
Каждый вывод хранит исходное событие, версию правила или модели и действие ответственного. Если контекста недостаточно, система не угадывает, а переводит событие на ручную проверку.
Business case / no invented ROI
Экономика начинается с потери, которую можно пересчитать.
До сметы мы не обещаем проценты эффективности. Сначала измеряем частоту события, стоимость ручной работы и ошибки, нагрузку на проверяющего и цену эксплуатации контура.
объём событий, в которых возникает проблема «КП собираются из старых файлов, содержат неактуальные условия и требуют ручной проверки каждой позиции.»
стоимость ручного действия, задержки или ошибки по показателю «время подготовки КП»
доля исключений, которые после запуска всё равно должен проверять человек
стоимость интеграции и сопровождения систем: CRM, ERP или 1С, шаблоны документов
Если измеримый эффект не покрывает стоимость контура и риск, задачу не нужно превращать в отдельный продукт.
Measurement
Как понять, что внедрение работает.
Источник: CRM. Базовая линия: 2–4 недели до пилота.
Источник: ERP или 1С. Базовая линия: 2–4 недели до пилота.
Источник: шаблоны документов. Базовая линия: 2–4 недели до пилота.
Сначала проверяем процесс, качество данных и владельца решения.
Генеративная модель не должна придумывать наличие, сроки или скидки вне источника данных.
Readiness check
Когда этот сценарий имеет смысл.
Автоматизация оправдана, когда проблема повторяется, влияет на управляемый показатель и у процесса есть владелец. Для сценария «Подготовка коммерческих предложений с ценовыми ограничениями» сначала проверяем не модель, а фактический маршрут работы.
- 01Повторяемость
Событие повторяется достаточно часто, чтобы измерять «время подготовки КП».
- 02Доступность данных
Первичные данные доступны в системах: CRM, ERP или 1С, шаблоны документов.
- 03Владелец решения
Владелец процесса готов отвечать за исключения и финальное решение.
- 04Ограниченный риск
Риск «Генеративная модель не должна придумывать наличие, сроки или скидки вне источника данных.» можно ограничить правилами, журналом и ручной проверкой.
Questions before code
Что нужно выяснить до выбора технологии.
Ответы отделяют реальную задачу от красивой демонстрации. Они же задают границы пилота и критерии остановки.
- Q1
Сколько раз за неделю возникает ситуация: КП собираются из старых файлов, содержат неактуальные условия и требуют ручной проверки каждой позиции.
- Q2
Где сегодня фиксируется время подготовки КП и можно ли восстановить исходное событие?
- Q3
Кто принимает решение после сигнала и за какое время он должен отреагировать?
- Q4
Какие ошибки системы недопустимы и когда решение обязательно передавать человеку?
Pilot / 4–8 weeks
Как запускать без большой ставки вслепую.
Зафиксировать текущий маршрут
Интервью с владельцем процесса, карта событий, исключения, права доступа и исходные значения KPI. На этом этапе может выясниться, что проблему надёжнее решает обычная логика, а не AI.
Собрать минимальный контекст
Подключаем только необходимые источники: CRM, ERP или 1С, шаблоны документов. Не строим озеро данных до появления первого работающего сценария.
Запустить на ограниченной зоне
Система формирует черновик по шаблону, каталогу и правилам скидок, а отклонения отправляет на согласование. Первые решения логируются, а низкая уверенность и исключения уходят человеку.
Сравнить с базовой линией
Смотрим на время подготовки КП, ошибки в условиях, доля согласований без возврата. Если процесс не изменился, не масштабируем интерфейс только ради уже написанного кода.
Пилот принимается по изменению время подготовки КП, ошибки в условиях, доля согласований без возврата, а не по количеству экранов и промптов.
Останавливаем масштабирование, если данные нестабильны, ответственный не использует сигнал или сохраняется риск: Генеративная модель не должна придумывать наличие, сроки или скидки вне источника данных.
How IT WHITE enters the project
Не продаём всю систему до проверки процесса.
100–180 тыс. ₽
Карта процесса, данные, потери, владелец решения, варианты архитектуры и предварительная экономика.
от 450 тыс. ₽
Одна ключевая задача, необходимые интеграции, роли, журнал решений, запуск и критерии результата.
от 100 тыс. ₽/мес.
Мониторинг, исправления, качество решений, новые правила, развитие интеграций и отчёт по работе системы.
Decision FAQ
Три вопроса, которые защищают проект от лишней сложности.
Здесь точно нужен AI?
Не обязательно. Если событие определяется стабильными правилами, обычная логика будет дешевле, быстрее и надёжнее. AI нужен там, где решение зависит от неструктурированного контекста.
Что подготовить к первичному разбору?
Один реальный пример сбоя, список систем (CRM, ERP или 1С, шаблоны документов), пример исходных данных и человека, который сегодня принимает финальное решение.
Что происходит при ошибке?
Система сохраняет исходные данные и причину вывода, не выполняет критическое действие без разрешения и передаёт исключение человеку. Главный риск сценария: Генеративная модель не должна придумывать наличие, сроки или скидки вне источника данных.
Evidence base
На каких рыночных сигналах основан сценарий.
Материал синтезирует публичные исследования и практики. Мы не переносим чужие кейсы на себя и не обещаем чужие показатели. Экономика рассчитывается только после анализа вашего процесса.
Related scenarios / Продажи и CRM
Следующие процессы в том же контуре.
Fit check / 20–30 min
Проверим сценарий «Подготовка коммерческих предложений с ценовыми ограничениями» на вашем процессе.
За 20–30 минут определим разрыв, доступные данные, владельца решения и разумный первый контур. Это бесплатная проверка соответствия задачи, не платная диагностика.