Как внедрить ИИ в отдел продаж: пилот на одном процессе без риска для CRM
Начните с одной повторяемой задачи. На примерах тендерных документов и Price-On показываем, как пилот превращается в рабочую автоматизацию.
Один из наших клиентов каждый день готовит коммерческие предложения и документы для участия в тендерах. Менеджер открывает старый файл, ищет подходящие блоки, переносит характеристики, проверяет требования заказчика и собирает новую версию. На следующий день всё повторяется.
Можно было купить сотрудникам подписку на нейросеть и объявить, что теперь в отделе продаж есть ИИ. Мы пошли от самой работы: разобрали, какие данные приходят на вход, какие разделы повторяются, где нельзя ошибаться и кто отвечает за финальную проверку.
Сначала автоматизировали подготовку черновика. Затем стало понятно, что решение может жить отдельно от одного проекта. Так из потребности клиента появился отдельный сервис, над которым мы сейчас работаем. Первый MVP уже есть, но публичного названия у него пока нет.
Для меня это нормальный путь внедрения ИИ: не искать место для модной технологии, а брать повторяемую задачу, считать ручной труд и проверять решение на реальных документах.
Начинайте с процесса, а не с подключения нейросети к CRM
Фраза «хотим ИИ в отдел продаж» почти ничего не объясняет. Я прошу описать один рабочий эпизод:
После каждого запроса менеджер собирает коммерческое предложение из нескольких файлов. Часть данных копирует вручную, часть уточняет у коллег. Руководитель возвращает документ, если пропущено требование или появилось неподтверждённое обещание.
Теперь задачу можно измерить. Сколько времени занимает документ? Какие блоки повторяются? Где чаще ошибаются? Что можно подготовить автоматически, а что должен подтвердить сотрудник?
Для первого пилота я выбираю процесс, который:
- повторяется несколько раз в неделю;
- использует доступные и разрешённые данные;
- выдаёт результат, который человек может проверить;
- имеет понятную базовую линию времени и ошибок.
Редкая стратегическая задача, решение по цене или самостоятельная отправка обязательств клиенту для первого пилота не подходят.
Реальный пример: коммерческие предложения и тендеры
В проекте с ежедневной подготовкой документов мы не ставили задачу «написать предложение одной кнопкой». Цена выдуманного факта здесь слишком высока: ошибка в характеристике, сроке или условии закупки может испортить заявку на тендер.
Мы разделили работу на части:
- Сервис получает требования и разрешённые материалы компании.
- ИИ находит нужные фрагменты и собирает структурированный черновик.
- Правила проверяют обязательные разделы и формат.
- Ответственный сотрудник сверяет факты, цены, сроки и обязательства.
- Только после подтверждения документ можно отправлять клиенту.
Так ИИ снимает повторяемую сборку, но не получает право обещать что-либо от лица компании. Во время пилота мы смотрим на время подготовки, количество ручных исправлений и причины возврата документа. Процент экономии я здесь не привожу: выборка ещё формируется, а MVP продолжает меняться.
Главный результат этого проекта шире одного сценария. Мы увидели повторяемую проблему и начали превращать внутреннее решение в отдельный продукт. До публичного запуска мы должны проверить его на разных форматах документов и понять, где универсальный шаблон заканчивается и начинается настройка под конкретную компанию.
Второй пример: из Excel-прайса вырос Price‑On
Не каждая полезная автоматизация должна начинаться с ИИ. Иногда задача проще и ценнее любой эффектной демонстрации.
Другой наш клиент часто обновлял большой прайс. Менеджеры пересылали Excel, покупатели открывали старые версии, а актуальность цены и наличия приходилось уточнять вручную. Клиенту нужен был не ещё один файл, а одна ссылка, за которой всегда находится свежий каталог.
Из этой задачи появился Price‑On. Компания загружает Excel-прайс и получает сайт-каталог с категориями, поиском и кнопками заказа. После обновления файла меняется каталог, а ссылка для покупателей остаётся той же. Заявка приходит менеджеру с товаром и артикулом.
Price‑On важен здесь как пример продуктового мышления. Сначала была конкретная рутина клиента, затем рабочее решение, а уже после — отдельный сервис. Мы не добавляли ИИ в каждый шаг ради этикетки. Там, где данные нужно обновлять по понятным правилам, обычная автоматизация надёжнее и дешевле модели.
Шесть процессов, с которых можно начать
1. Сводка разговора и следующий шаг
Модель получает расшифровку и готовит черновик: задача клиента, ограничения, участники решения, договорённости и следующее действие. Менеджер сверяет текст с записью и подтверждает перенос в CRM.
Измеряйте общее время обработки, долю исправленных полей и карточки без следующего действия.
2. Письмо после встречи
ИИ собирает письмо по утверждённой структуре и фактам разговора. Цена, срок и характеристики берутся только из разрешённого источника.
Проверяйте время до отправки и фактические ошибки. Быстрый черновик не приносит пользы, если менеджер переписывает его целиком.
3. Контроль чистоты CRM
Система находит активные карточки без ответственного, следующего шага или обязательного поля. Для большей части проверки хватает обычных правил. ИИ помогает разбирать свободный текст и объяснять исключения.
На первом этапе модель не должна закрывать сделки и менять коммерческий статус.
4. Группировка причин отказа
Менеджеры записывают одну причину разными словами. Модель может разнести комментарии по утверждённому справочнику: продукт, регион, бюджет, срок, конкурент, нет ответа, дубль или спам.
Человек проверяет неоднозначные строки. В отчёте становится меньше бесполезного «другое», а причины можно сравнить по источникам обращений.
5. Проверка разговора по чек-листу
ИИ отмечает, уточнил ли менеджер задачу, согласовал ли следующий контакт и не обещал ли неподтверждённый срок. Рядом с выводом нужен фрагмент исходной записи.
Я не советую превращать такую проверку в скрытый рейтинг сотрудников. Команда должна знать критерии и иметь возможность оспорить ошибочный вывод.
6. Черновик коммерческого предложения
Модель собирает документ из утверждённых модулей: задача клиента, состав работ, ограничения, этапы и следующий шаг. Цена и обязательства подтверждаются ответственным сотрудником.
Этот сценарий похож на наш проект с тендерными документами, но границы пилота у каждой компании будут своими.
Соберите паспорт пилота на одной странице
Я использую короткий документ, чтобы эксперимент не растянулся без решения.
- Процесс — одно действие сотрудника, которое меняется.
- Пользователь — конкретная роль или небольшая группа.
- Входные данные — поля, файлы и система-источник.
- Результат — черновик, классификация или предупреждение.
- Проверка человеком — кто подтверждает результат и по каким правилам.
- Базовая линия — время, ошибки и полнота до пилота.
- Метрика эффекта — одно–три измеримых изменения.
- Ограничения — что модели запрещено делать.
- Срок — фиксированный период и дата разбора.
- Решение — масштабировать, доработать или остановить.
Период зависит от частоты процесса. Команда с десятками звонков в день соберёт материал быстрее отдела, который готовит два сложных тендера в месяц. Обещать процент улучшения до базовой линии бессмысленно.
Подготовьте данные и доступы
До интеграции я задаю пять вопросов:
- Какие данные действительно нужны модели?
- Есть ли среди них контакты, записи разговоров, цены и коммерческие условия?
- Где будут храниться входы, выходы и журналы?
- Кто получит доступ и как его отозвать?
- Можно ли начать с обезличенного тестового набора?
У разных продуктов разные правила обработки данных. OpenAI, например, указывает, что по умолчанию не использует данные организаций из ChatGPT Business, Enterprise и API для обучения моделей [1]. Это свойство конкретных продуктов, а не общее правило для любого сервиса. До запуска нужно проверить условия выбранного поставщика и требования самой компании.
Минимизируйте входные данные. Для классификации причины отказа модели не нужен телефон клиента. Для проверки следующего шага часто достаточно обезличенного текста и стадии сделки.
Сначала измерьте ручную работу
Возьмите обычную выборку и запишите:
- медианное время на задачу;
- долю заполненных обязательных полей;
- количество фактических ошибок;
- долю результата, принятого без возврата;
- просроченные действия, если сценарий на них влияет.
После пилота измерьте те же показатели на сопоставимой работе. Не смешивайте новых сотрудников с опытными, а типовое предложение — со сложным тендером.
Сэкономленные минуты не доказывают пользу сами по себе. Если сотрудник быстро получил черновик, но дольше проверяет факты, стоимость процесса могла вырасти.
Запустите пилот в шесть шагов
- Опишите процесс и базовую линию.
- Соберите обезличенные примеры с эталонным результатом.
- Зафиксируйте формат ответа и запреты.
- Проведите тест вне рабочей CRM.
- Подключите небольшую группу с обязательным подтверждением.
- Разберите ошибки и примите решение по заранее заданным метрикам.
Количество примеров зависит от разнообразия задачи. Набор из десяти или тридцати документов не даёт статистической гарантии. Он помогает увидеть типовые ошибки до доступа к рабочему процессу.
Где человек остаётся обязательным
На первом пилоте сотрудник подтверждает:
- факты и договорённости после разговора;
- цену, срок и коммерческие обязательства;
- изменение стадии сделки;
- отправку сообщения или документа клиенту;
- решение об отказе или приоритете лида.
Ручная проверка не мешает автоматизации. Она даёт материал для следующей версии и показывает реальную цену ошибки.
Когда пилот нужно остановить
- Модель добавляет факты, которых нет в источниках.
- Сотрудники исправляют один тип ошибки снова и снова.
- Нет журнала входов, выходов и подтверждений.
- Эффект виден только на специально выбранных примерах.
- Команда обходит инструмент и возвращается к старому процессу.
- Никто не может объяснить, какие данные покидают корпоративный контур.
Остановка тоже даёт результат: вы узнаёте границы сценария до дорогой интеграции и можете выбрать более простой процесс.
Чек-лист первого внедрения
- ☐ Выбран один повторяемый процесс.
- ☐ Собрана базовая линия времени и качества.
- ☐ Входные данные минимизированы и разрешены.
- ☐ Есть тестовый набор и эталонные ответы.
- ☐ Человек подтверждает результат до действия в CRM.
- ☐ Ошибки записываются по категориям.
- ☐ Дата решения и критерии масштабирования заданы заранее.
В ConversOn мы начинаем с участка, где эффект можно проверить. Иногда из пилота вырастает отдельный продукт, как сервис подготовки коммерческих предложений. Иногда проблема приводит к более простой автоматизации, как Price‑On. В обоих случаях отправная точка одна: реальная работа клиента, которую можно описать, измерить и улучшить. Если хотите выбрать такой процесс для своей команды, можно обсудить пилот ИИ.