Какой процесс в продажах подходит для первого пилота?

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

ИИ для отдела продаж: с чего начать

Q: Нужно ли начинать с чат-бота?

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

Q: Может ли ИИ принимать решения вместо менеджера?

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

Начинать внедрение ИИ в отделе продаж следует не с выбора модели и не с идеи «сделать чат-бота», а с одного повторяемого участка, где компания регулярно теряет время или выручку. Хороший первый процесс имеет измеримый объём, доступные данные, понятного владельца и короткий цикл обратной связи. Это может быть разбор входящих заявок, поиск потерянных лидов, подготовка коммерческого предложения, заполнение CRM или контроль обещанного следующего шага. До пилота фиксируют базовую линию и стоимость ошибки, затем ограничивают один тип сделок или одну команду. ИИ сначала готовит решение, а сотрудник подтверждает его. Масштабирование начинается только после проверки эффекта, качества и ежедневного использования.

Кому актуален первый AI-пилот
Где искать стартовую задачу
Признаки подходящего процесса
Экономика первого кейса
Варианты решения
Схема пилота
План внедрения
Ошибки
Чек-лист
FAQ

Кому актуален первый AI-пилот

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

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

Где искать стартовую задачу

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

Частые зоны для проверки:

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

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

Признаки подходящего процесса

Хорошая стартовая задача повторяется достаточно часто, чтобы пилот дал наблюдаемую выборку. У неё есть вход и выход: например, входом служит письмо со спецификацией, выходом — черновик КП и заполненная карточка. Есть критерий качества, который может проверить сотрудник. Данные доступны законно и технически, а владелец процесса готов изменить регламент.

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

Экономика первого кейса

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

| Элемент | Условные исходные данные | Как проверить | |---|---:|---| | Новых обращений | 600 в месяц | CRM и почта | | Время первичного разбора | 9 минут | хронометраж выборки | | Повторный ручной ввод | 4 минуты | наблюдение процесса | | Обращения без следующего шага | 8% | аудит карточек | | Стоимость часа сотрудника | 900 ₽ | управленческий расчёт |

Если подготовка и перенос данных сокращаются в условном примере на 5 минут, потенциально высвобождается 600 × 5 / 60 = 50 часов в месяц. При расчётной стоимости часа 900 ₽ это 45 000 ₽ ресурса. Но это не автоматически полученная прибыль. Руководитель должен определить, будет ли время направлено на большее число контактов, обработку дополнительного потока или сокращение задержек. Эффект от возвращённых лидов считают отдельно и только по фактически восстановленным сделкам, а не по всей сумме открытых возможностей.

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

Варианты решения

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

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

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

Схема пилота

[Письмо / звонок / форма]
             │
             ▼
 [Сбор контекста сделки]
             │
             ▼
 [ИИ: извлечение и черновик]
             │
       ┌─────┴─────┐
       ▼           ▼
 [Менеджер]   [Правила риска]
       │           │
       └─────┬─────┘
             ▼
 [CRM + следующий шаг + журнал]
             │
             ▼
 [KPI: время, качество, использование]

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

План внедрения

Выбрать один поток. Например, только входящие письма определённого типа, а не весь отдел и все каналы.
Снять базовую линию. Измерить объём, время первого действия, полноту CRM, долю исправлений и пропусков.
Определить риск. Какие действия система только предлагает, какие выполняет после подтверждения, какие запрещены.
Подготовить данные. Проверить справочники, обязательные поля, права доступа и примеры корректных результатов.
Собрать рабочий маршрут. Включить очередь исключений, журнал и уведомление ответственному.
Запустить на небольшой группе. Выбрать сотрудников, которые готовы отмечать ошибки и причины исправлений.
Проверять еженедельно. Смотреть не только среднее время, но и сложные кейсы, отказы, ручные обходы.
Изменить регламент. Убрать дублирующие действия и закрепить новый порядок работы.
Принять решение. Масштабировать, доработать или остановить гипотезу на основании заранее выбранного KPI.

Как выбрать между несколькими гипотезами

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

Полезно провести короткий «ручной прототип»: аналитик или руководитель выполняет предполагаемую работу по новым правилам на небольшой выборке, не создавая интеграцию. Такой тест показывает, действительно ли подготовленное резюме помогает менеджеру, какие сведения отсутствуют и где требуется экспертное решение. Результат ручного прототипа уточняет требования и позволяет отказаться от слабой гипотезы до разработки. Все наблюдения записывают как данные для решения, а не как обещание будущего эффекта.

Ошибки

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

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

Чек-лист

[ ] Выбрана одна измеримая потеря, а не абстрактная цель.
[ ] Определены вход, выход и владелец процесса.
[ ] Есть достаточная выборка реальных кейсов, включая исключения.
[ ] Зафиксированы базовые время, качество и доля пропусков.
[ ] Один главный KPI согласован до разработки.
[ ] Коммерчески значимые действия имеют человеческое подтверждение.
[ ] Определены источники данных и права доступа.
[ ] Результат и исправления записываются в журнал.
[ ] Пилот не заставляет вести две версии одних данных.
[ ] У команды есть правило масштабирования или остановки.

FAQ

Нужно ли начинать с чат-бота?

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

Какой процесс подходит для первого пилота?

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

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

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

Связанное решение

Commercial Desk собирает контекст входящего запроса, помогает подготовить рабочий черновик и передать результат в коммерческий процесс. Для поиска сделок без следующего шага связанным контуром служит Revenue Control.

Выберите первый процесс на данных

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