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

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

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

Что означает ИИ для анализа продаж

Здесь полезно разделять три типа анализа.

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

Прогнозный анализ сложнее. Для него нужна история сопоставимых сделок с известным результатом. Если этапы заполнялись по-разному, процесс менялся, а закрытых сделок мало, прогноз может выглядеть убедительно, но не быть надёжным.

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

Общий обзор сценариев есть в статье «ИИ для продаж». Здесь мы разбираем именно анализ накопленных данных.

Когда ИИ-анализ действительно нужен

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

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

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

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

Быстрый тест готовности:

1. Есть конкретный вопрос, а не желание «внедрить ИИ».
2. Понятно, какое решение будет принято после анализа.
3. Нужные данные доступны и связаны со сделками.
4. Есть сотрудник, который знает процесс и проверит выводы.
5. Можно измерить результат до и после пилота.
6. Ошибочный ответ не приведёт к необратимому действию без проверки.

Начните с бизнес-вопроса

Запрос «проанализируй наши продажи» слишком широкий. Рабочий сценарий лучше описать так:

вопрос → данные → результат → действие → ответственный → проверка

Пример:

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

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

Какие данные подготовить

Для анализа B2B-сделок обычно нужны:

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

История этапов важнее одного текущего значения. Без неё нельзя восстановить, сколько времени сделка провела на каждом этапе и возвращалась ли назад.

До анализа проверьте данные:

• Пропуски. Если у половины проигранных сделок нет причины, модель не восстановит достоверную картину.
• Дубли. Повторные компании, сделки и активности искажают количество, суммы и частоту причин.
• Этапы. Если один этап означает разные ситуации, сравнивать время на нём бессмысленно.
• Тестовые записи. Учебные карточки и старые импорты нужно исключить или анализировать отдельно.
• Валюты. Суммы нельзя складывать без явного правила пересчёта.
• Связи. Звонок без номера сделки трудно сопоставить с движением по воронке.
• Свежесть. У отчёта должна быть дата обновления, иначе уже обработанная сделка может попасть в список проблемных.

Что можно анализировать

Застрявшие сделки

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

Лучше проверять несколько признаков:

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

ИИ готовит список и объяснение. Правило, после какого срока сделка считается застрявшей, определяет сама компания.

Причины потерь

Формальная причина часто не передаёт детали. За значением «неактуально» могут скрываться отсутствие бюджета, перенос решения, выбор конкурента или несоответствие продукта.

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

Звонки и встречи

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

На первой проверке система должна только составлять список. Автоматически создавать задачи и менять этапы стоит после разбора ошибок на реальных разговорах.

Оценка вероятности и прогноз

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

Требования зависят от продукта. Например, Microsoft Dynamics 365 требует для стандартной модели не менее 40 выигранных и 40 проигранных возможностей за выбранный период. Это порог конкретного сервиса, а не универсальный стандарт качества.

Прогноз может быть слабым даже на большой выборке, если:

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

Качество проверяют на новых сделках, которые не использовались для настройки модели.

Резюме для руководителя

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

Два примера первого пилота

Пилот 1. Сделки без следующего действия

Проблема: воронка большая, но непонятно, какие сделки действительно находятся в работе.

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

Результат: список подозрительных сделок с причиной включения и ссылкой на исходную запись.

Проверка человека: действительно ли нет следующего шага, не было ли контакта в другой системе и нормален ли такой срок для сегмента.

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

Пилот 2. Причины проигрыша

Проблема: в отчёте много значений «Другая причина», хотя подробности есть в заметках.

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

Результат: понятные группы причин, исходные формулировки и записи, которые не удалось уверенно классифицировать.

Проверка человека: подтверждается ли категория текстом, не смешаны ли разные причины и можно ли на основании группы изменить процесс.

Что ИИ не может доказать

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

Есть и другие ограничения:

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

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

Как не превратить аналитику в слежку

Записи разговоров и индивидуальная статистика затрагивают приватность сотрудников и клиентов. До подключения определите:

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

Оценку ИИ нельзя использовать как единственное основание для премии, увольнения или понижения. Microsoft отдельно предупреждает, что показатели Conversation Intelligence не предназначены для решений о занятости и компенсации работников.

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

Таблица, готовый сервис или собственная система

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

О выборе системы подробнее написано в статье про CRM для автоматизации продаж. Если система должна сама выполнять последовательность действий, прочитайте материал про ИИ-агентов для продаж.

До передачи данных поставщику уточните:

1. Какие записи будут доступны системе?
2. Может ли она изменять данные или только читать?
3. Где происходит обработка и хранение?
4. Каков срок хранения?
5. Используются ли данные для обучения общих моделей?
6. Как устроено удаление?
7. Какие права и журналы действий доступны?
8. Какие языки поддерживаются?
9. Из чего складывается стоимость при росте объёма?

Как провести первый пилот

1. Выберите один вопрос. Не объединяйте в одном тесте воронку, звонки, прогноз и автоматические действия.
2. Сохраните исходное состояние. Например, время подготовки отчёта и количество сделок без следующего шага.
3. Ограничьте выборку. Возьмите один продукт, сегмент, команду или период.
4. Проверьте данные. Найдите пропуски, дубли, тестовые записи и разные валюты.
5. Подготовьте правильные ответы. Сотрудник вручную размечает часть реальных записей без помощи ИИ. Затем ответы модели сравнивают с этой контрольной выборкой.
6. Запретите автоматические изменения. Сначала система только предлагает результат.
7. Сохраняйте объяснение. У вывода должны быть исходная запись и причина включения.
8. Разберите ошибки. Отдельно считайте пропущенные проблемы, ложные предупреждения и искажённые резюме.
9. Оцените пользу. Учитывайте время анализа, проверки и исправлений, а не только скорость модели.
10. Примите решение. Масштабируйте, измените правила и повторите тест либо откажитесь от сценария.

Когда пилот можно масштабировать

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

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

С чего начать

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

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

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

Использованные источники

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

• Microsoft Learn: настройка прогнозной оценки сделок
• Microsoft Learn: резюме и разбор звонка
• Microsoft Learn: Conversation Intelligence и ограничения при оценке сотрудников
• HubSpot: стандартные свойства сделки и даты активности
• Microsoft Learn: обработка дубликатов в Power Query
• Google for Developers: утечка результата и расхождение данных при обучении и применении модели
• NIST: AI Risk Management Framework
• European Commission: разъяснения по применению AI Act
• ICO: рекомендации по мониторингу работников
• OpenAI: почему языковые модели могут выдавать недостоверные ответы
• OpenAI: обработка данных корпоративных клиентов