Короткий ответ. Приёмка результатов AI-поиска начинается с контрольных компаний и заранее записанных решений: принять кандидата, вернуть на проверку или отклонить. До записи в CRM проверяют подтверждения фактов, соответствие профилю и дубли. Оценивают весь путь до принятой записи, включая ручную проверку, а не только скорость получения списка.
Маршрут поиска и состав профиля разобраны в руководстве по поиску B2B-клиентов с ИИ. Для приёмки ниже нужны проверочный набор, правила решений и воспроизводимый результат.
Почему поиск начинается с базы знаний
Если агенту дать только команду «найди клиентов», он не знает, кому предложение подходит. Ему нужны проверяемые ответы: какие задачи решает продукт, для каких компаний он предназначен, какие условия обязательны, какие признаки означают «не подходит», что можно обещать, а что требует согласования. Источники должны иметь владельца, дату актуальности и статус. Устаревшая презентация не должна перевешивать действующие условия.
Из этих данных собирают профиль целевой компании. Например: отрасль, регион, масштаб, наличие конкретной операции, технологический контекст и причина для разговора. Каждый критерий делят на обязательный, желательный и исключающий. Так поиск становится воспроизводимым: другой сотрудник может понять, почему компания попала в подборку.
От открытого источника до карточки CRM
Полезный маршрут можно описать шестью шагами:
- Зафиксировать гипотезу о подходящем сегменте и критерий успеха.
- Найти организации в согласованных источниках и сохранить ссылку на источник каждого факта.
- Сверить профиль компании с критериями, указать пробелы и степень уверенности.
- Проверить, нет ли уже компании, контакта или сделки в CRM.
- Подготовить краткую карточку: чем занимается компания, почему она подходит, что проверить перед обращением.
- Передать запись сотруднику на решение; внешнее сообщение отправлять только в рамках утверждённого сценария и прав.
CRM здесь — место продолжения работы, а не корзина для найденных ссылок. Запись должна содержать источник, дату проверки, краткое обоснование, владельца и следующий шаг. Если сведения не подтверждены, это поле отмечают как неизвестное, а не заполняют догадкой.
Где агенту нужна граница полномочий
Поиск в открытых источниках и создание черновика записи — разные действия с разными рисками. Можно разрешить агенту читать утверждённый набор страниц и готовить кандидатов, но потребовать подтверждения человека для создания сделки, назначения ответственного или отправки сообщения. Права на данные должны соответствовать роли, а журнал — позволять восстановить, какие источники и правила привели к рекомендации.
Не следует собирать из интернета любые персональные данные только потому, что они доступны по ссылке. Для проекта заранее определяют законные источники, допустимые поля, срок хранения и сценарий контакта; спорные случаи проверяет ответственное лицо. Нельзя скрывать автоматизацию за фиктивным профилем сотрудника или выдавать предположение агента за факт.
Как оценить пилот без красивых, но пустых цифр
На первом этапе полезны показатели качества процесса: доля кандидатов с источником, доля дубликатов, точность соответствия профилю по ручной выборке, доля карточек, которые менеджер принял без существенной правки, и время от находки до решения. Количество найденных компаний само по себе не говорит о ценности: тысяча неподходящих записей создаёт нагрузку на команду.
Сравнивайте работу агента и текущий ручной процесс на одинаковой выборке. Определите правила разметки заранее, сохраните исходные результаты и фиксируйте причины отклонения. Если меняется профиль целевой компании, отдельно версионируйте гипотезу, чтобы не смешивать эффект инструмента и эффект нового критерия.
Где здесь Цифра
Цифра показывает рабочую модель, где контекст компании, задачи команды и сделки можно рассматривать в одном процессе. Конкретные источники поиска, права агента и интеграции зависят от конфигурации и выбранной CRM. Перед запуском согласуют, что система только предлагает, что сохраняет, а что выполняет после подтверждения.
Начать можно с одного сегмента и ограниченного набора полей. Это позволяет проверить качество источников и критериев до расширения потока. Подробнее о Цифре и AI-CRM, о базе знаний компании и автоматизации CRM.
Профиль клиента: признаки, источник и уверенность
Для каждого критерия целевой компании задайте не только название, но и наблюдаемое подтверждение. «Компания быстро растёт» — оценка. «На сайте опубликованы вакансии по двум направлениям продаж и открыто новое представительство» — два наблюдения со ссылками и датами. Агент должен отделять факты из источника от гипотезы о потребности. Если публичные данные не подтверждают обязательный критерий, кандидат не проходит отбор.
Удобно завести таблицу с полями: критерий; почему он важен; допустимый источник; дата проверки; статус подтверждения; комментарий; кто проверяет. Для отраслевых терминов добавьте синонимы и исключения. Например, система может спутать производителя и реселлера, если классифицирует только по словам из описания. Набор правил сначала проверяют на небольшом списке организаций, размеченном сотрудником.
Не позволяйте одному совпадению решать всё. Совпадение отраслевого слова не подтверждает размер компании, роль собеседника или готовность к разговору. Если критерии конфликтуют, покажите конфликт и пропустите запись на ручную проверку. Задайте отдельный статус «недостаточно данных», чтобы он не смешивался с «не подходит».
Пример маршрута на условной компании
Допустим, команда продаёт систему учёта заявок компаниям с распределённой сетью филиалов. В условном примере агент находит страницу организации с адресами нескольких офисов, но не находит подтверждения, что входящие обращения распределяются вручную. Правильный результат — указать подтверждённый признак филиальной структуры и пробел по процессу обращений. Рекомендация менеджеру может звучать как вопрос для проверки, но не как факт «у компании теряются заявки».
Это учебный сценарий на вымышленных данных, не клиентский кейс и не результат Цифры. Его ценность — в демонстрации языка неопределённости. В пилоте команда может спорить о том, достаточно ли филиалов для включения в сегмент. Такие разногласия стоит записать как решение по критерию, а не прятать в свободной заметке.
Проверка совпадений и объединение записей
Одна организация может быть записана на русском и английском языках, иметь несколько доменов, филиалы и юридические лица. Слишком строгая проверка создаёт дубли, слишком широкая — объединяет разные компании. Поэтому правила нужно подстроить под объект учёта: бренд, юридическое лицо или группа компаний. Перед массовой записью прогоните пары похожих названий и выпишите, какие случаи система должна объединять, а какие оставлять отдельно.
В сомнительном совпадении агенту лучше предложить кандидатов на сопоставление, показать доказательства и дождаться решения. Автоматическое объединение должно быть обратимым и сохранять историю. Не удаляйте источники и прежние значения полей после слияния.
Этапы пилота и критерий приёмки
Установите границу выборки: например, один сегмент и один набор открытых источников. Отберите примеры подходящих и неподходящих компаний до запуска. Независимый сотрудник оценивает те же записи по одной рубрике: источник проверяем; критерии подтверждены; дубликат распознан; рекомендация не выдаёт гипотезу за факт. При разногласии пересмотрите рубрику, а не только ответ модели.
Полезно разделить пилот на два режима. В режиме «только предложение» агент формирует список и ничего не пишет в CRM. В режиме «черновик» он подготавливает поля, которые человек проверяет перед сохранением. Только после стабильной работы обеих частей можно обсуждать более автоматизированный маршрут. Это снижает риск накапливать ошибки при одновременной проверке качества поиска и интеграции.
Заранее задайте стоп-критерии: неизвестно происхождение источника; доля дублей превышает согласованный порог; обязательные поля систематически неверны; команда не успевает проверять кандидатов; изменились условия предложения. Решение «пока не масштабировать» — нормальная часть пилота.
Экономика процесса
Сравнивайте полную стоимость подготовки одного пригодного кандидата, а не количество найденных доменов. Включите время настройки профиля, ручную проверку, исправление дублей, заполнение CRM, обучение команды и поддержку интеграции. Сравнение с ручным способом имеет смысл только на похожем сегменте и с одинаковым определением пригодности.
Наблюдайте, сколько рекомендаций сотрудник принимает, отклоняет и существенно редактирует. В причинах отказа выделяйте: не тот сегмент; неверный источник; отсутствует информация; дубликат; компания не актуальна; предложение не соответствует. Эта обратная связь показывает, что улучшать: базу знаний, запрос, критерий, источники или сам маршрут.
Что подготовить до поиска B2B-клиентов с помощью ИИ
Составьте паспорт предложения на одну страницу. В нём нужны задача покупателя, результат вашей работы, условия применимости и подтверждение, которое можно показать потенциальному клиенту. Если продукт полезен только после подключения телефонии, этот факт должен быть обязательным критерием. Если команда работает лишь с определённым регионом, ограничение должно участвовать в поиске раньше, чем агент начнёт собирать контакты.
Рядом сохраните список причин отказа от кандидата. В него могут входить неподходящий масштаб, отсутствие нужного процесса, действующий контракт с ограничением или запрет на контакт по внутреннему регламенту. Агент должен проверять исключения до подготовки сообщения. Тогда найденная информация служит принятию решения, а не создаёт видимость движения в CRM.
Отделите известную задачу клиента от возможного повода для разговора. Вакансия руководителя продаж может указывать на изменение команды, но не доказывает проблему с контролем звонков. В карточке кандидата допустима формулировка «есть повод уточнить процесс», а не «нуждается в нашем продукте». Такой язык помогает менеджеру не строить разговор на неподтверждённом предположении.
Какие источники искать и как сравнивать сведения
Задайте порядок доверия источникам по типу факта. Для описания собственного продукта компании её официальный сайт обычно полезнее каталога, который давно не обновлялся. Для текущего адреса стоит сверить несколько публичных страниц, если они расходятся. Если искомая характеристика нигде не раскрыта, система должна оставить её неизвестной: отсутствие подтверждения не превращается автоматически в отрицательный ответ.
В карточку факта включайте адрес страницы и короткий фрагмент, на котором основан вывод. Не нужно копировать весь сайт в CRM. Сотруднику достаточно открыть первоисточник и быстро проверить спорное утверждение. Если страницу обновили, сохранённая дата наблюдения объяснит, почему агент видел другие условия. Для существенных изменений назначайте повторную проверку, а не бессрочно используйте старую выдержку.
Разделяйте поиск и чтение результата. Название страницы в выдаче может содержать нужную фразу, но основной текст не подтверждает критерий. Агенту нельзя принимать сниппет за окончательное доказательство. Если переход не удался, сохраните ссылку в статусе «источник не прочитан» и предложите сотруднику проверить его. Это лучше, чем заполнить пробел сведениями о похожей организации.
Как составить объяснимую оценку кандидата
Вместо одного непрозрачного балла используйте несколько независимых статусов: сегмент подтверждён; обязательная предпосылка подтверждена; найдена причина для уточнения; источник актуален; контактный маршрут разрешён. Рейтинг можно добавить для сортировки очереди, но рядом остаются основания. Менеджер должен видеть, почему одна запись стоит выше другой и какое действие может изменить её статус.
Не приравнивайте «подходит по профилю» к «готов к покупке». Готовность требует данных о потребности, участниках решения, сроках и условиях. Публичный поиск часто не даёт таких сведений. На этом этапе агент помогает сформировать разумный вопрос, а не заявляет, что обнаружил квалифицированную возможность. Воронка должна отражать эту разницу: исследовательский кандидат ещё не является сделкой с подтверждённой потребностью.
Периодически берите не только верхние рекомендации, но и случайные записи из середины и отклонённой группы. Иначе команда видит исключительно удобные примеры и не замечает, что правило отбрасывает подходящих клиентов. Причины ручного пересмотра сохраняйте структурированно: они помогут уточнить критерии без изменения всей системы.
Поля карточки, которые действительно нужны менеджеру
| Поле | Что в нём хранить | Чего избегать |
|---|---|---|
| Компания | Проверенное название и сайт | Название, восстановленное по догадке |
| Основание отбора | Конкретный подтверждённый признак | Общую оценку «перспективная» |
| Источник | URL, фрагмент, дата наблюдения | Ссылку только на поисковую выдачу |
| Неизвестное | Вопрос, который ещё нужно выяснить | Выдуманный бюджет или потребность |
| Следующий шаг | Действие, владелец, условие выполнения | Задачу «проработать» без результата |
| Решение человека | Принять, уточнить, отклонить и причина | Молчаливое удаление рекомендации |
Поля источника и решения не должны исчезать после переноса в CRM. Если сотрудник меняет название или обоснование, сохраняйте исходную рекомендацию и дату правки. Это позволит разобрать, где агент ошибся и где менеджер добавил знания из разговора. Без такой истории улучшения превращаются в спор о том, что система якобы предложила.
От списка кандидатов к первому разговору
После исследования подготовьте короткий бриф для менеджера: что известно, что предполагается, какой вопрос нужно задать и какой материал можно предложить. Обращение должно соответствовать роли адресата. Если неизвестно, кто занимается процессом, сначала выясняют ответственного, а не обещают решение всему предприятию. Имя и должность нельзя подставлять из профиля человека с похожими данными.
Система может предложить несколько вариантов следующего шага: проверить контактный маршрут, уточнить критерий, связать кандидата с существующей компанией или закрыть запись. Внешнее сообщение становится отдельной операцией с собственными правилами. Даже хороший исследовательский агент может быть не готов к переговорам: качество поиска не доказывает качество голоса, письма или обработки возражений.
После разговора обновите гипотезу. Если выяснилось, что компания не подходит из-за нового ограничения, это знание стоит передать владельцу профиля. Но не нужно автоматически менять критерии по одному отказу: менеджер может иметь дело с исключением. Решение об изменении сегмента принимают по накопленным основаниям и сохраняют отдельной версией.
Как посчитать полезность без выдуманного прогноза продаж
Для сравнения процесса возьмите одинаковое определение принятого кандидата. Например, это запись с проверенным сайтом, подтверждёнными обязательными признаками и понятным следующим шагом. Посчитайте затраты времени на поиск, чтение, проверку, дубли и сохранение. Если ИИ ускоряет получение списка, но увеличивает время проверки каждого пункта, полезность надо оценивать по всему маршруту.
В условном расчёте команда тратит 90 минут на подбор и принимает шесть записей из десяти. Другая версия даёт двадцать записей за 30 минут, но проверка занимает ещё два часа и принимаются те же шесть. Это иллюстрация метода, а не данные Цифры: число находок выросло, а итоговая производительность не улучшилась. Такой пример помогает выбрать правильную единицу измерения.
Отдельно учитывайте нагрузку очереди. Если система создаёт больше кандидатов, чем менеджеры могут проверить, увеличивается возраст данных и пропадает преимущество быстрого поиска. Ограничьте размер незавершённой очереди, назначьте срок пересмотра и определите, что архивируется. Работающий процесс заканчивается решением по записи, а не её созданием.
Какие материалы запросить у подрядчика на приёмке
Попросите показать один сквозной прогон на согласованных примерах: входная база знаний, критерии, найденные источники, решение по кандидатам, поиск дублей и итоговые поля. Выберите примеры сами из тестового набора. Приёмка только по заранее подготовленным удачным демонстрациям не показывает поведение на обычной работе.
В комплект передачи включите описание источников, схему полей, роли, журнал ошибок, порядок обновления профиля и инструкцию отключения записи в CRM. Уточните, какие расходы возникают при повторной проверке и какие части зависят от внешних сервисов. Сотрудники должны уметь продолжить ручную работу, если поиск или интеграция временно недоступны.
Контрольный набор для приёмки выдачи AI-поиска
Возьмите условный набор из пяти ситуаций. Это образец теста, а не результат работы Цифры или клиентский кейс. Для каждой строки заранее запишите ожидаемый исход, нужные подтверждения и поля, которые допустимо сохранить. Исполнитель получает критерии, но не только заранее удобные компании: часть примеров выбирает принимающий сотрудник.
| Ситуация в контрольном наборе | Ожидаемое решение | Что должен увидеть принимающий |
|---|---|---|
| Компания соответствует профилю, факты подтверждены актуальными страницами | Допустить к записи после проверки дублей | Источники, даты и заполненные обязательные поля |
| Подходит название, но услуга относится к другому юридическому лицу | Вернуть на уточнение | Разделённые сущности и причина сомнения |
| Компания уже присутствует в CRM под вариантом названия | Не создавать повторную запись | Найденное совпадение и основание проверки |
| Важный признак встречается только в старой публикации | Пометить факт как неподтверждённый | Дата источника и поле, которое осталось пустым |
| Сайт недоступен или возвращает ошибку | Отложить проверку без выдуманного результата | Причина, время попытки и следующий шаг |
Приёмка проходит на одинаковом наборе для сравниваемых версий. Если меняются критерии профиля, сохраните новую версию задания и пересмотрите ожидаемые решения. Иначе улучшение качества модели легко спутать с более мягкими правилами допуска. Ошибка на строке с дублем и ошибка на строке с недоступным сайтом требуют разных исправлений: одного общего процента недостаточно.
Отдельно проверьте повторный прогон. Он не должен создавать вторую карточку только потому, что проверка запущена ещё раз. Сохраните журнал: входные материалы, найденные подтверждения, решение сотрудника и итоговые поля. По этому комплекту другой специалист должен понять, почему запись приняли. Затем можно расширять контрольный набор случаями из собственной практики, сохраняя обезличенные примеры и действующие правила доступа.
Первичные материалы
- REST API Битрикс24: CRM — Сущности, методы и связи CRM.
- NIST AI RMF Playbook: Map — Описание контекста, границ применения и роли человека.
- OWASP: риски приложений с большими языковыми моделями — Обзор угроз и контрольных мер для приложений с LLM.