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