Контрольная группа для ИИ-продавца: как сравнить продажи честно

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

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

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

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

Клиент как единица назначения, а не отдельный звонок

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

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

На странице агентской CRM «Цифра» можно посмотреть опубликованные возможности продукта и формат обсуждения задачи «спланировать контрольную группу для ИИ-продавца». Наличие конкретных интеграций, согласований и ограничений доступа проверяют отдельно; описанная здесь схема — проектные требования, а не автоматически доступная настройка.

Условный пример: двадцать клиентов и один менеджер

В условной компании двадцать клиентов делят на две равные группы. В первой работает ИИ-продавец по согласованному сценарию, во второй — прежний порядок звонков. Результат — заказ, подтверждённый сотрудником в CRM, в заранее заданном окне тридцать дней. Пример условный; он нужен не для вывода о продажах, а для поиска места, где сравнение ломается.

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

Карточка проверки: что фиксируют до первого контакта

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

Для сверки терминов о заказе и его строке можно открыть описание создания и обработки заказа в Microsoft Dynamics 365 Sales. Это внешний пример описания заказа, а не подтверждение конкретной настройки в другом продукте.

Гипотеза, критерий допуска и результат до запуска

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

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

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

Загрязнение через перехват сложных клиентов

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

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

Новая кампания меняет состав групп

В условном примере компания запускает проверку на сорока клиентах: двадцать в одной группе, двадцать в другой. Через неделю стартует отдельная рассылка, которая задевает двенадцать клиентов первой группы и четырёх клиентов второй. Формально назначение не менялось, фактически условия стали разными.

Если кампания — часть обычной работы, её нужно либо заморозить на окно проверки, либо учитывать как отдельное воздействие. Нельзя задним числом объявить клиентов «неподходящими» только потому, что они получили лишнее касание. Проще заранее записать: кампании в окно не запускаются, а если запускаются, проверка останавливается.

Два воздействия на одного клиента

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

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

Результат, который созрел позже окна

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

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

Отказы, исключённые после просмотра

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

Рекомендация: правила исключения фиксируют до старта и применяют одинаково к обеим группам. Если клиент не подходит по границам проверки, его исключают до назначения, а не после звонка. Всё, что произошло после назначения, остаётся в журнале.

Малое число покупок не доказывает равенство

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

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

Интерфейс сотрудника: где видно назначение и запрет ручного переноса

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

В проектных требованиях для агентской CRM «Цифра» описывают поиск клиентов, подготовку карточек, согласованные сообщения и звонки; изменение этапа, суммы и ответственного согласует сотрудник. Это описание роли, а не подтверждение конкретной настройки. Для общего образца разграничения доступа можно посмотреть роли безопасности и полномочия в Microsoft Power Platform, а для образца согласования — принятие и отклонение запросов в Power Automate. Эти документы не доказывают наличие таких функций в другом продукте; они помогают описать требования к процессу.

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

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

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

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

Тесты процесса до сравнения продаж

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

Практикум на другом примере и один шаг проверки

В условном практикуме тридцать шесть обращений делят на две группы по восемнадцать. Результат — заказ, подтверждённый сотрудником, окно — двадцать один день. Через десять дней менеджер хочет забрать трёх «сложных» клиентов из группы с ИИ. Вопрос практикума простой: что должно произойти, чтобы сравнение осталось пригодным?

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

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

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

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

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

Соседний вопрос разобран отдельно: Как измерить эффект от внедрения AI в продажах. Здесь основной предмет — назначение групп на уровне клиента, загрязнение эксперимента и заранее выбранный результат; не общая оценка ROI.