С чего начать разбор потерянных B2B-заявок
Разбор начинается с узкой группы сопоставимых случаев: например, заявок после коммерческого предложения, не завершившихся сделкой. Для каждой фиксируют наблюдаемый исход и доступные сведения о потребности, сроке, договорённостях и следующем шаге. ИИ может свести заметки к хронологии и выделить повторяющиеся формулировки, чтобы команда видела не россыпь впечатлений, а структуру записей.
До анализа стоит согласовать словарь исходов. «Договор не подписан» — результат; «срок запуска не подошёл» — возможная причина, только если это подтверждено разговором. Для неясных случаев нужна категория «причина неизвестна»: она не маскирует пробел догадкой. Так запрос «нейросеть для анализа продаж» превращается в конкретную задачу: сравнивать записи по одинаковым определениям и проверять основания каждой гипотезы.
Что исследование продаж говорит о выборе задач для ИИ
В шестом издании Salesforce State of Sales, опубликованном 25 июля 2024 года, опросили 5 500 специалистов из 27 стран в марте–апреле 2024 года. Респонденты оценили, что 70% времени продавцов уходит на задачи вне непосредственных продаж. Это самоотчёт участников международного опроса, а не хронометраж российских компаний; показатель не означает, что всё такое время можно устранить.
Опрос даёт контекст для выбора административных задач, где стоит проверить применимость ИИ, но не изучает причины потери B2B-заявок и не измеряет эффект этого сценария. Поэтому цифра помогает сформулировать предмет проверки, а не предрешает её результат.
Условный пример: от записи в CRM к проверяемой гипотезе
- Входные сведения
Условно, в CRM записано: клиент запросил интеграцию к определённой дате, затем перенёс запуск, а после встречи не подтвердил следующий шаг. ИИ упорядочивает разрешённые заметки по времени и извлекает зафиксированные факты. На выходе — последовательность событий с указанием исходных записей, а не свободный пересказ намерений клиента.
- Гипотеза с основаниями
Если мотив переноса не указан, система должна показать пробел, а не подменять его версией о неготовности клиента. Она может выделить связь между обсуждением срока и ходом сделки, приложив фрагменты, на которых основана подсказка. Если объяснений несколько, их оставляют вариантами для проверки.
- Проверка и фиксация
Сотрудник сверяет подсказку с историей контакта, подтверждает категорию или исправляет её. В CRM фиксируется основание решения; если причина неясна, отмечают, какого факта не хватает. Это делает последующий разбор понятным: команда видит, где изменилась интерпретация, а где были уточнены исходные сведения.
Где заканчивается полезная подсказка ИИ и начинается ошибка
| Наблюдение | Ошибочный вывод | Что проверить |
|---|---|---|
| Указана цена, затем нет ответа | Отказ из-за цены | Есть ли прямое подтверждение причины |
| Перенесён срок запуска | Клиент не готов | Зафиксирован ли мотив переноса |
| В заметках разные объяснения | Выбрать самое частое | Какие записи относятся к первичному разговору |
| Отказ смешан с неквалифицированной заявкой | Считать одним исходом | Совпадают ли определения категорий |
Как оценить, стал ли разбор полезнее
Сравнение проводят на ограниченной выборке с заранее заданным периодом и одинаковыми правилами завершения разбора. Доля предложенных причин, которые продавцы подтвердили или исправили, показывает, насколько подсказки пригодны для работы; число карточек с недостатком данных помогает оценить качество исходных записей. Эти показатели отвечают на разные вопросы, поэтому их лучше рассматривать отдельно, а не сводить в условный общий балл.
Отдельно сравнивают время разбора одной заявки по прежнему процессу и со сводкой ИИ, включая проверку человеком. Чтобы сравнение имело смысл, одинаково определяют начало и конец работы. Если время выросло, но исправлений стало меньше, это может быть полезным компромиссом; вывод зависит от того, что команда считает ценностью процесса.
По результатам можно уточнить словарь причин, требования к CRM-полям или формат сводки — в зависимости от того, где возникают расхождения. Для более широкой темы о том, как организовать ИИ-автоматизацию продаж, есть отдельный материал.
Для сопоставления полезно заранее зафиксировать базовый процесс: кто разбирает карточку, какие поля открывает и что считает завершением. Затем выборку распределяют по периодам или сопоставимым группам, не меняя определений на ходу. Если одновременно поменять CRM-форму, правила квалификации и подсказку, станет трудно понять, какое изменение повлияло на наблюдаемые показатели.
Разбор расхождений тоже даёт практический результат. Например, если несколько сотрудников по-разному трактуют одну и ту же категорию, сначала уточняют её границы и проверяют примеры на общей выборке. Если спорные случаи сосредоточены вокруг конкретного поля, команда может изменить способ его заполнения. Так корректируется именно узкое место процесса, а не просто формулировка запроса к ИИ.