Сценарии ИИ для бизнеса в отделе продаж: что поручать, а что оставлять человеку

Автор: Виталий Дильдин · Опубликовано 14 июля 2026 года

Короткий ответ

Полезный сценарий ИИ для отдела продаж описывается не названием сервиса, а рабочим контрактом: на каком этапе он включается, какие данные получает, что возвращает и кто проверяет результат. «Использовать нейросеть в продажах» — тема. «По подтверждённым заметкам встречи подготовить черновик follow-up без новых цен, сроков и обещаний» — сценарий, который можно проверить.

При выборе первого пилота важны повторяемость задачи, готовность данных, обратимость ошибки и цена неправильного ответа. Чем легче сотруднику увидеть ошибку до контакта с клиентом, тем безопаснее старт. Поэтому подготовка черновика, списка вопросов или структуры заметки обычно подходит для проверки лучше, чем автоматическая отправка, изменение статуса лида или самостоятельное обещание условий.

ИИ не должен придумывать факты о клиенте, цены или обязательства. За итоговое сообщение и решение отвечает сотрудник. Зрелый маршрут идёт от ручного помощника к согласованному шаблону и только затем к интеграции. Автономный агент не является обязательной целью каждого сценария.

Как эта страница связана с соседними материалами

Если задача — обучить команду и выстроить общие правила, смотрите курс ИИ для отдела продаж. Если сценарий уже выбран и нужно назначить доступы, тесты, метрики и остановку, переходите к руководству по внедрению ИИ в продажи. Общий материал о выборе AI-пилота сравнивает задачи разных подразделений; здесь рассматривается только воронка продаж.

Примеры ниже — модельные рабочие ситуации. Это не клиентские кейсы, не отзывы и не обещание экономического эффекта. Их задача — помочь составить собственный тест на данных и правилах компании.

Как выбирать сценарии

Начните с карты процесса: входящее обращение, квалификация, подготовка контакта, встреча, follow-up, предложение, передача следующего шага, обновление CRM, анализ причин отказа. Для каждого этапа соберите повторяемые операции и отметьте, где сотрудник работает с текстом, структурой или классификацией.

Затем оцените каждую операцию по шести вопросам:

1. Есть ли понятный вход? Например, заметки встречи, карточка CRM или утверждённый шаблон.
2. Можно ли описать выход? Черновик, список вопросов, набор тегов или подсказка по заполнению.
3. Кто проверяет? Конкретная роль, а не «команда».
4. Как выглядит критическая ошибка? Выдуманный факт, неверная цена, потерянное возражение, некорректный статус.
5. Можно ли отменить действие? Черновик легко отклонить; отправленное письмо вернуть нельзя.
6. Хватает ли разрешённых данных? Если контекст живёт в личной переписке и не фиксируется, сначала улучшите процесс.

NIST в AI RMF Core относит к функции Map определение назначения, пользователей, контекста, ограничений и бизнес-ценности применения ИИ. Это полезная проверка здравого смысла: сценарий нельзя оценить вне конкретного процесса и последствий ошибки. Рамка добровольная и межотраслевая; она не заменяет внутренние правила или применимое право.

Сценарии по этапам продаж

1. Разбор входящего обращения

Задача. Выделить из сообщения тему, продукт, срочность, известные ограничения и недостающие сведения.

Вход. Текст обращения без лишних данных плюс утверждённый справочник категорий.

Выход. Предложение категории и список вопросов для уточнения.

Проверка. Сотрудник сверяет исходное сообщение, подтверждает категорию и решает, кому передать обращение. ИИ не должен отказывать клиенту, определять его ценность или менять очередь без установленного правила.

Сценарий подходит, если категории действительно используются и менеджеры одинаково понимают их смысл. Если справочник устарел, модель лишь замаскирует проблему аккуратным текстом.

2. Подготовка к первому разговору

Задача. Собрать подтверждённые сведения, заметить пробелы и предложить вопросы для квалификации.

Вход. Карточка лида, источник обращения, история разрешённых коммуникаций и критерии квалификации.

Выход. Краткая справка с отдельными блоками «факты», «неизвестно», «вопросы».

Проверка. Менеджер должен видеть, откуда взят каждый факт. Предположение о потребности нельзя помещать в блок фактов. Оценку перспективности принимает человек по процессу компании.

3. Черновик follow-up после встречи

Задача. Превратить заметки в письмо с итогами и следующим шагом.

Вход. Подтверждённые заметки, согласованная структура и допустимый тон.

Выход. Черновик письма, где договорённости отделены от открытых вопросов.

Проверка. Имена, даты, цены, сроки, обязательства и вложения сверяются человеком. Если в заметках нет следующего шага, система должна обозначить пробел, а не придумать его.

Это хороший ручной пилот: письмо не отправляется без подтверждения, а ошибки можно классифицировать. После устойчивой проверки сценарий можно превратить в шаблон, но автоматическая отправка остаётся отдельным решением с более высокой ценой ошибки.

4. Структурирование заметки для CRM

Задача. Предложить распределение свободного текста по согласованным полям.

Вход. Заметка менеджера, схема полей и допустимые значения справочников.

Выход. Предпросмотр предлагаемых значений с указанием неизвестного.

Проверка. Сотрудник сравнивает исходник и структуру, подтверждает запись. Пустое поле лучше выдуманного. Автоматическое изменение истории, суммы, статуса или ответственного не входит в первый безопасный вариант.

Если такой сценарий созрел для интеграции, технический маршрут можно изучить в программе n8n и AI-автоматизация. Сначала, однако, нужна устойчивая ручная проверка.

5. Подготовка структуры коммерческого предложения

Задача. Собрать каркас документа под известные требования клиента.

Вход. Подтверждённые требования, утверждённый каталог предложений, шаблон и ограничения.

Выход. Структура с пометками, где не хватает данных.

Проверка. Цена, объём, сроки, юридические условия и обещания добавляются или подтверждаются уполномоченным сотрудником. Нельзя просить модель «сделать предложение убедительнее», если это означает придумать функции, опыт или результаты.

6. Разбор коммуникации по чек-листу

Задача. Найти в расшифровке элементы согласованного процесса: выявление контекста, вопросы, зафиксированный следующий шаг.

Вход. Разрешённая расшифровка и прозрачный чек-лист.

Выход. Ссылки на фрагменты и вопросы для разбора с руководителем.

Проверка. Оценка не должна автоматически становиться кадровым решением. Расшифровка может быть неточной, критерии — неполными, а контекст разговора — шире текста. Сценарий лучше использовать для обучения и самопроверки, а не для скрытого рейтинга людей.

7. Классификация причин отказа

Задача. Предложить категорию по заметке и выделить неоднозначные случаи.

Вход. Согласованный справочник причин и текст с подтверждённым исходом.

Выход. Предложенная категория, уверенность не в числовом обещании, а в объяснении опорных фрагментов и отметке «нужна проверка».

Проверка. Менеджер подтверждает категорию. Если причины отказа смешаны, полезнее сохранить несколько факторов или отправить случай на разбор, чем заставлять систему выбирать один удобный ответ.

8. Поиск пробелов в карточке

Задача. Сравнить заполнение карточки с требованиями этапа.

Вход. Поля CRM и правило обязательности.

Выход. Список отсутствующих или противоречивых данных.

Проверка. Система не восстанавливает неизвестное по догадке. Этот сценарий часто не требует генеративного ИИ: обычные правила CRM могут быть дешевле, прозрачнее и надёжнее. Наличие модели не должно быть условием решения.

Матрица решения

Для сравнения кандидатов добавьте частоту, время ручной операции, доступность данных и сложность проверки. Экономику считайте на собственных наблюдениях через калькулятор ROI автоматизации, не используя чужие проценты как доказательство будущего эффекта.

Пошаговая проверка пилота

1. Напишите контракт сценария

Одним абзацем опишите событие, разрешённый вход, выход, запреты и проверяющего. Если абзац превращается в список разных задач, сузьте сценарий.

2. Соберите разные типы примеров

Нужны не только «хорошие» записи. Добавьте неполный вход, противоречие, неизвестную категорию, длинную заметку и пример, где правильный ответ — запросить уточнение.

3. Определите критические ошибки

Для follow-up это могут быть новая цена, несуществующая договорённость или неправильный адресат. Для CRM — выдуманное значение или изменение поля без подтверждения. Критические ошибки оцениваются отдельно от стиля.

4. Проведите ручной тест

Сотрудник копирует разрешённый контекст, получает черновик и заполняет короткий чек-лист. Сохраняйте причины отклонения, а не только итоговый текст. Так видно, где нужна инструкция, дополнительное поле или отказ от сценария.

5. Проверьте стабильность

NIST AI RMF рекомендует связывать методы измерения с рисками конкретного контекста, тестировать до развертывания и регулярно в работе. Повторите тест после изменения модели, шаблона, интеграции или набора данных. Один удачный пример ничего не говорит о стабильности.

6. Выберите уровень зрелости

Уровень 1 — ручной помощник. Уровень 2 — общий шаблон и чек-лист. Уровень 3 — предпросмотр внутри процесса. Уровень 4 — ограниченное действие с журналом и возможностью остановки. Переход нужен только если предыдущий уровень подтверждён и дополнительная автоматизация оправдывает риск.

Типичные ошибки

Выбирать инструмент раньше задачи. Команда начинает искать применение купленной функции и принимает любую демонстрацию за полезный процесс.

Смешивать несколько этапов. Запрос одновременно анализирует клиента, пишет письмо, меняет CRM и назначает задачу. Причину ошибки невозможно локализовать.

Считать красивый текст качественным. В продажах критичны факты и обязательства, а не гладкость формулировки.

Обучать на идеальном примере. Реальная работа содержит пропуски, противоречия и нестандартные запросы. Тест должен это отражать.

Сразу давать право действия. Генерация и отправка — разные уровни риска. Сначала человек видит и подтверждает результат.

Игнорировать не-AI решение. Проверка обязательных полей, шаблон или правило маршрутизации иногда решают задачу прозрачнее генеративной модели.

Ограничения

Генеративный ИИ может искажать факты, терять важное условие и добавлять правдоподобные детали. Он не знает внутренних договорённостей, если они не предоставлены в допустимом контексте, и не должен заполнять пробелы догадками.

Использование клиентских и внутренних данных требует решения компании о допустимых сервисах, доступах, хранении и проверке. При высокой цене ошибки привлекайте владельца данных, информационную безопасность и юриста. Эта статья не определяет правовой режим конкретных данных.

NIST Generative AI Profile описывает риски, которые возникают или усиливаются при генеративном ИИ, и группирует предлагаемые действия вокруг управления, происхождения контента, предзапускового тестирования и раскрытия инцидентов. Практический вывод для отдела продаж прост: происхождение факта, тест и канал сообщения об ошибке нужны до расширения доступа.

AI-агент имеет смысл только при ограниченных действиях, наблюдаемом состоянии и проверенном способе остановки. Перед таким переходом полезно изучить курс по AI-агентам для бизнеса и проверить, не решается ли задача более простой автоматизацией.

Частые вопросы

Какой сценарий выбрать первым?

Тот, у которого понятный вход, обратимый выход, частая операция и быстрый человеческий контроль. Обычно это подготовка, структурирование или подсказка, а не автоматическое решение.

Можно ли использовать ИИ для персонализации писем?

Можно готовить черновик по подтверждённому контексту. Сотрудник проверяет факты, уместность, тон и обещания. Массовая автоматическая персонализация без контроля повышает риск ошибок и безличных сообщений.

Нужна ли интеграция с CRM?

Не для проверки ценности. Сначала проведите ручной тест. Интеграция оправдана, когда поля и правила стабильны, а предпросмотр и остановка спроектированы.

Может ли ИИ оценивать менеджеров?

Он может помочь собрать наблюдения по прозрачному чек-листу, но расшифровки и критерии имеют ограничения. Не используйте автоматически сформированную оценку как единственное основание значимого решения о сотруднике.

Как понять, что сценарий не подходит?

Если нет разрешённых данных, невозможно описать критическую ошибку, проверка сложнее исходной операции или действие нельзя безопасно отменить, сценарий стоит отложить, сузить или заменить обычным правилом.

Следующий шаг

Выберите три повторяемые операции отдела продаж и заполните для каждой строку: этап, вход, выход, источник фактов, критическая ошибка, проверяющий и обратимость. Оставьте для пилота один сценарий с самым понятным контролем. Затем соберите разные типы примеров и проверьте его вручную, не подключая автоматическую отправку или изменение CRM.