Что можно считать основанием для метки источника
ИИ полезен здесь не как угадыватель канала, а как помощник в проверке согласованности. Он сопоставляет метку в CRM с доступными полями и показывает, какие из них поддерживают её, какие расходятся, а каких сведений не хватает. Например, пометка «форма сайта» может проверяться по сохранённому событию формы и его связи с записью лида. Итогом должна быть не только краткая оценка, но и перечень использованных оснований, чтобы сотрудник мог открыть те же поля.
До настройки нужно договориться, что именно команда называет источником. Первое касание, канал последнего контакта и причина, по которой человек оставил заявку, могут различаться. Если считать их одним понятием, система получит неоднозначное правило, а два сотрудника по одной записи смогут дать разные ответы. Зафиксируйте определения и допустимые значения отдельно; для каждого укажите, какое поле или связанное событие может его подтвердить.
В исследовании Microsoft Research, опубликованном в 2025 году, опрос охватил 319 работников умственного труда, а качественный анализ включил 936 примеров применения генеративного ИИ. Авторы описывают работу с проверкой информации, интеграцией ответа и управлением задачей. Это самоотчёты и качественный анализ, а не измерение точности проверки CRM-меток или её влияния на продажи. Поэтому источник помогает объяснить роль проверки, но не подтверждает эффективность конкретного правила атрибуции.
Чтобы правило было воспроизводимым, запишите его в форме «если наблюдаются такие-то поля, статус может быть таким-то; при отсутствии связи — такой-то». Укажите и исключения: например, несколько заявок одного контакта за короткий период или повторная отправка формы. Не нужно заранее покрывать все редкие ситуации. Достаточно определить, какие записи правило обрабатывает однозначно, а какие направляет на ручное уточнение. Такой перечень становится общей инструкцией и для сотрудников, и для модели.
Как сопоставить метку с полями CRM
Для автоматизации отдела продаж сначала задайте границы контекста: текущая запись, явно связанные события и согласованный временной интервал. Не передавайте модели весь массив CRM, если для решения достаточно одной карточки и связанных с ней записей. Это снижает риск смешать сведения о разных контактах и упрощает последующую проверку.
Полезно разделить работу на два шага. Сначала ИИ извлекает точные значения полей и указывает их названия; затем применяет заданное правило и формирует объяснение. Если вывод неверен, такой формат помогает понять, где причина: поле прочитано неправильно, событие связано не с тем лидом или само правило допускает несколько трактовок. Таблица показывает типы проверки, а не универсальную схему полей: состав зависит от того, что действительно хранится в вашей CRM.
Запрос к модели можно сформулировать без расплывчатого «определи источник». Например: «Сопоставь значение поля source с событиями, связанными с lead_id; выведи значения, даты и идентификаторы; отметь соответствие правилу; при конфликте перечисли обе версии; если связи нет, укажи, какое поле отсутствует». Такой формат задаёт ожидаемую структуру ответа, но не меняет само правило атрибуции.
Перед использованием проверьте, что названия полей и статусы в запросе совпадают с реальной CRM. Если поле называется иначе или хранит несколько значений, модель может построить аккуратное, но неверное объяснение. Полезно также исключить из контекста свободные комментарии, не связанные с записью, либо помечать их отдельно: иначе совпадение слов может выглядеть как подтверждение события.
| Метка | Что сопоставить | Что сообщает ИИ | Действие сотрудника |
|---|---|---|---|
| Форма сайта | Событие отправки формы и связь с лидом | Связь найдена либо отсутствует | Открыть событие и проверить идентификатор |
| Рекомендация | Поле рекомендации или связанная заметка | Основание, пробел или конфликт | Уточнить значение по согласованному правилу |
| Реклама | Канал, кампания и дата события | Согласованность полей | Проверить связь события с записью |
| Не указан | Доступные сведения о канале | Какие сведения есть и чего нет | Оставить статус неопределённым |
Как разобрать запись с двумя возможными источниками
Условный пример: в CRM стоит метка «форма сайта», а комментарий к карточке говорит, что человек позвонил после рекомендации. ИИ должен вывести оба фрагмента рядом, показать даты и связи с лидом, а не выбрать более убедительно звучащую версию. Сотрудник проверяет, относятся ли комментарий и событие формы к одному обращению. Возможно, форма была первым касанием, а звонок — следующим; возможно, комментарий относится к другой записи.
Если две версии относятся к разным этапам пути клиента, их не обязательно сводить к одному значению. В CRM могут отдельно храниться первый источник, источник конкретного обращения и последний контакт — при условии, что команда различает эти поля и знает, для какого отчёта каждое используется. Если связать события не удаётся, сотрудник может сохранить статус «не определён» и указать, какого поля не хватило. Это не окончательный вывод о происхождении обращения, а аккуратная фиксация текущего состояния данных.
На практике полезно сохранить рядом с результатом не только текстовое резюме, но и ссылки на конкретные поля или идентификаторы событий. Тогда следующий сотрудник сможет проверить основание, не повторяя поиск по всей карточке. Если в CRM нет функции ссылок, достаточно вывести точные названия полей и значения. Не просите систему переписывать всю историю контакта: короткая выборка, относящаяся к правилу, легче проверяется и меньше отвлекает от противоречия.
Как оценить, помогает ли проверка команде
Полезная оценка показывает не только число совпадений, но и структуру ошибок. Разделите расхождения по причинам: неверно прочитанное поле, устаревшее событие, ошибочная связь с лидом, неоднозначное правило или отсутствие данных. Для каждой причины укажите, кто способен её исправить и где именно меняется процесс. Так результат превращается в очередь конкретных улучшений, а не в спор о том, «хорошо ли работает ИИ».
Чтобы сравнение было содержательным, сохраните для каждой записи версию правила, дату проверки и основания, на которых получен статус. Затем можно отдельно посмотреть, повторяется ли один тип расхождения после изменения процесса. Например, если записи с несколькими обращениями стабильно попадают в категорию «не определён», это сигнал не обязательно улучшать модель: возможно, CRM нужно различать первое касание и источник конкретной заявки.
Если сотрудники расходятся между собой ещё до сравнения с ИИ, сначала разберите, какое определение допускает разные трактовки. Зафиксируйте решение в справочнике правила и добавьте к нему один пограничный пример. При следующем обучении новых сотрудников этот пример покажет, как применять критерий к неоднозначной записи. Отдельно отмечайте случаи, когда данные объективно не позволяют установить источник: корректное «не определён» полезнее уверенного, но не подкреплённого ответа.
Как проверить, сохраняется ли контекст при переходе лида между этапами, разбираем в материале о передаче обращения между этапами продаж. Для выбора подходящих сценариев работы ИИ в продажах смотрите ИИ-автоматизацию продаж.
- Согласуйте эталон
Выберите записи и определите для каждой ожидаемый статус по одному письменному правилу. Не меняйте критерий после просмотра ответа ИИ.
- Разметьте тип результата
Для каждой записи отметьте совпадение, противоречие или недостаток данных. Отдельно зафиксируйте, какое поле или связь вызвали спор.
- Сравните одинаковые случаи
Проверьте выводы ИИ и сотрудников на одних и тех же записях. Разберите несовпадения по причинам, а не только по общей доле совпавших меток.
- Решите, что менять
Если мешает отсутствие поля — улучшите сбор данных; если правило допускает двойное толкование — уточните его; если неверна связь событий — проверьте процесс переноса записей.