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