Как превратить запрос клиента в задание для ИИ
Практическая задача — не поручить модели «написать хорошее предложение», а получить точную постановку для продавца. В запросе клиента могут соседствовать потребность, ограничения, желаемый срок и данные, которых пока нет. Рабочий результат ИИ — краткое задание, где каждое требование связано с исходной формулировкой, а пробелы вынесены отдельно.
Для этого задают схему результата: требование, подтверждающий фрагмент письма, степень определённости и вопрос для уточнения. Правила нормализации заранее описывают формат дат, валют, единиц и названий комплектаций. Это помогает отличить изменение формата от изменения смысла: «в начале осени» можно сохранить как цитату, но нельзя без основания превратить в конкретный день.
При длинной переписке важно учитывать последовательность сообщений. Если клиент позднее меняет количество, задание должно показать новое значение и сослаться на уточнение, а не незаметно склеить старую и новую версии. Для сотрудника полезны и исходный фрагмент, и краткое объяснение того, почему поле помечено как изменённое.
Выход удобно разделить на подтверждённые параметры, открытые вопросы и противоречия. Тогда продавец видит, что уже можно передать на расчёт, а что пока требует решения. Такой формат превращает ответ модели из гладкого пересказа в рабочую основу: каждое поле можно проверить по письму, а неоднозначность не маскируется уверенным тоном.
Какие данные исследования применимы к подготовке предложений
В Salesforce State of Sales, опубликованном 25 июля 2024 года, о росте выручки сообщили 83% команд, использовавших ИИ, и 66% команд без него. Отдельно респонденты оценили долю времени на задачи вне непосредственных продаж в 70% — это указывает на заметный пласт административной работы, но не измеряет подготовку коммерческих предложений напрямую. Опрос охватил 5 500 специалистов из 27 стран; данные собирали в марте–апреле 2024 года. Это самоотчёты, а различие между группами — корреляция, не причинный эффект ИИ и не прогноз результата отдельной компании.
Условный пример: от письма клиента к заданию
- Исходное письмо
Условный клиент пишет: «Нужны 40 комплектов для двух площадок к началу сентября; монтаж обсудим отдельно». Это пример, а не реальный клиентский случай.
- Что извлекает ИИ
Система фиксирует количество, две площадки и желаемый срок. Оборот о монтаже сохраняет как отдельную тему для уточнения, не включая услугу в состав работ автоматически.
- Что остаётся неизвестным
В задании отмечаются точная дата и год, адреса площадок, состав комплекта, распределение количества и статус монтажа. Для каждого пробела указывается, какое решение он блокирует: например, расчёт поставки или состава предложения.
- Что получает продавец
Черновик отделяет сведения письма от открытых пунктов. Продавец сверяет, верно ли поняты исходные формулировки, и выбирает, какие вопросы задать клиенту до расчёта.
Как сравнить варианты при конфликте требований
| Ситуация в переписке | Что делает ИИ | Что решает продавец |
|---|---|---|
| В раннем письме один объём, в позднем другой | Показывает оба фрагмента и отмечает хронологию | Подтверждает, что позднее значение заменяет прежнее |
| В разных сообщениях указаны разные сроки | Не выбирает срок автоматически, связывает даты с сообщениями | Уточняет приоритет и фиксирует согласованный срок |
| Название услуги есть в подписи, но не в запросе | Не трактует подпись как заказанную услугу | Проверяет, входит ли услуга в предмет предложения |
| Клиент перечисляет два несовместимых требования | Формулирует конфликт отдельным пунктом без слияния условий | Запрашивает выбор или согласует допустимый вариант |
Как проверить задание перед подготовкой предложения
Проверку полезно строить вокруг существенных исправлений, а не гладкости формулировок. Отмечайте отдельно пропуск требования, неверное значение, ошибочную нормализацию и неверно распознанную неопределённость. Так видно, какая часть схемы нуждается в доработке; стилистическая правка сама по себе не равна фактической ошибке.
Для сравнения берите запросы одного типа и сохраняйте одинаковый формат результата. Если одновременно меняются инструкция и набор полей, трудно понять, что повлияло на качество. Зафиксируйте исходный текст, версию правил, черновик модели и итоговую правку продавца: это даёт возможность разобрать конкретный сбой, а не полагаться на общее впечатление.
Показатели пилота могут включать долю извлечённых пунктов, подтверждённых без содержательной правки, категории ошибок и время проверки сотрудником. Смотрите распределение, а не только среднее: типовые короткие запросы и редкие сложные переписки создают разную нагрузку. До начала сравнения определите, какие ошибки критичны для расчёта и какие лишь требуют редакторской коррекции.
Если проверка показывает, что модель регулярно смешивает старые и новые условия, уточняют правила работы с историей переписки. Если проблемы возникают из-за неполных исходных данных, полезнее изменить форму уточнения, а не усложнять инструкцию. Смежную тему передачи обращения между этапами продаж разбираем отдельно. Общий подход к автоматизации отдела продаж также помогает увидеть, как встроить такую задачу в процесс.