ИИ-SDR для B2B: шаблон процесса, в котором продажи остаются под контролем команды
ИИ-SDR для B2B: шаблон процесса, в котором продажи остаются под контролем команды. Практический разбор с промптами, примером и точками проверки.

ИИ-SDR полезен для подготовки: разобрать список компаний, найти публичные сигналы, собрать черновик персонализации и зафиксировать результат в CRM. Переписка от имени компании, обещания клиенту и изменение данных требуют согласованного процесса и ответственного человека.
Исходный шаблон опирается на OpenClaw. Перед установкой отдельно проверьте текущую документацию, модель доступа и правила хранения данных: продукт развивается, а связка с CRM и каналами создаёт риск лишних разрешений. В статье важен процесс, который переносим между инструментами.
Сначала опишите ICP: отрасль, размер, география, роль собеседника, триггеры, стоп-факторы. Затем соберите карточку лида из разрешённых источников и попросите ИИ отделить факт от предположения.
По карточке компании [данные] подготовь исследовательскую заметку для SDR.
Верни: подтверждённые факты с URL, гипотезы отдельно, возможный триггер,
два вопроса для первой беседы. Не придумывай должности, цифры или кейсы.
Сделай черновик первого письма до 700 знаков. Используй только подтверждённые
факты из заметки, один конкретный вопрос и нейтральную тему. Не обещай результат
и не отправляй письмо: результат нужен для проверки менеджером.
Пример проверки: менеджер берёт десять подготовленных карточек и сверяет URL, должность, отрасль и персонализацию. Если хотя бы один факт не подтверждён, его шаблон попадает в список для доработки. До масштабирования задайте лимит отправок, правило остановки и журнал действий.
Как устроен SDR-процесс
Первый этап — список компаний. Менеджер описывает сегмент: отрасль, размер, регион, роль, тип задачи и исключения. Затем фиксирует разрешённые источники: сайт компании, публичные вакансии, отраслевые публикации, собственная CRM. Агенту не нужен максимальный сбор данных; ему нужна достаточная информация для следующего действия.
Второй этап — исследовательская карточка. Агент возвращает ссылку, факт, дату и цитату; отдельно пишет гипотезы. «На сайте есть вакансия руководителя продаж» — факт. «Компании срочно требуется новая CRM» — гипотеза. Менеджер видит обе части и решает, есть ли повод для контакта.
Собери карточку лида в JSON: компания, URL, отрасль, роль контакта,
факты с цитатами, гипотезы, триггер, стоп-факторы, вопрос менеджеру.
Если источника нет, оставь поле пустым.
Третий этап — черновик. В нём одна уместная деталь, понятная польза и один вопрос. Менеджер утверждает текст, канал и адресата. Четвёртый — фиксация реакции в CRM: дата, источник, версия сообщения, статус согласования, ответ. Эта обратная связь показывает, какой сегмент и какое сообщение дают разговоры.
Пилот на две недели: 30–50 компаний одного сегмента, шаблон карточки и пять эталонных примеров. Первые пять проверяются совместно, затем менеджер случайно берёт каждую пятую. Метрики: верные URL, неподтверждённые факты, время подготовки, доля черновиков после лёгкой правки. Любая неверная идентификация компании останавливает поток до разбора причины.
Нужны отдельный рабочий аккаунт, ограниченные права, журнал запросов, список разрешённых доменов и быстрый отзыв доступа. Архитектура вторична: сначала проверьте, что карточка и сообщение полезны менеджеру. Содержательную персонализацию создают проверяемая ситуация и уместный вопрос.
Где в этой схеме находится OpenClaw
OpenClaw связывает агента, инструменты и каналы взаимодействия. Для первого SDR-пилота достаточно выделенного рабочего окружения, списка разрешённых источников и папки для карточек. Подключение модели, CRM и почты — отдельные технические шаги; готовность каждого проверяется в установленной версии. Документация OpenClaw описывает платформу и её компоненты.
В настройке полезно разделить исследование и внешнее действие. Исследователь получает право читать согласованные материалы и сохранять результат в рабочую папку. Менеджер смотрит карточку, утверждает текст и сам выполняет отправку в привычном канале. Когда этот маршрут станет устойчивым, можно проектировать отдельный инструмент отправки с проверкой согласования.
Доступы ограничиваются техническими настройками. Фраза в промпте о запрете отправки полезна как инструкция, но для исследовательского контура также уберите сам инструмент отправки. В официальном разделе безопасности OpenClaw разобраны политики инструментов, доступ к каналам, изоляция и журналирование. Там же описана команда openclaw security audit для проверки конфигурации.
Карточка, по которой удобно принимать решение
Начните с устойчивого идентификатора компании: домен плюс внутренний номер CRM. Это помогает отличить одноимённые организации. Затем добавьте отрасль, географию, источник каждого факта, дату просмотра и статус проверки. Контактное лицо указывайте только при наличии подтверждения, подходящего для выбранного способа связи.
В учебном примере поставщик складского оборудования видит на сайте компании объявление об открытии нового склада. Карточка содержит URL публикации и точную формулировку. Возможная потребность в оборудовании записывается как гипотеза. В черновике менеджер может спросить, кто отвечает за оснащение новой площадки, если такой контакт уместен и разрешён правилами компании.
При этом слово «расширяется» требует основания: один новый адрес иногда означает переезд. Агент должен сохранить исходное событие и дать менеджеру возможность уточнить вывод. Такая мелочь напрямую влияет на то, насколько письмо выглядит осмысленным для получателя.
Что делать с ответом и сбоем
Для реакции лида заведите понятные статусы: нужен ответ менеджера, запрошены материалы, контакт оказался неверным, отказ, просьба прекратить сообщения. Последняя категория должна сразу исключать повторный контакт в этом процессе. Правила каналов и допустимость коммуникации проверяет ответственная сторона до запуска.
Если запись в CRM прервалась, сначала прочитайте текущее состояние записи. Повторная попытка вслепую может создать дубль или дважды изменить статус. Каждому обработанному событию нужен идентификатор, по которому система понимает, выполнялось ли действие. Конкретный способ зависит от CRM и интеграции; разработчик проверяет его на тестовой записи.
Полезный тест: намеренно передать недоступную ссылку, карточку без домена и компанию из исключённого сегмента. Ожидаемые результаты — отметка о недоступном источнике, запрос уточнения и остановка обработки соответственно. В этих ситуациях агент должен сохранять уже проверенные данные.
Разбор пилота с руководителем продаж
Через две недели сравните карточки с исходным ручным процессом. Посчитайте, сколько минут заняли исследование и проверка вместе. Отдельно оцените исправления фактов, правки тона и полностью отклонённые черновики. Высокая скорость генерации теряет смысл, если менеджер долго восстанавливает источники.
Затем просмотрите причины отказа от карточек: неверный сегмент, слабый повод, устаревшая публикация, недостаточные данные. У каждой причины своё исправление — уточнить ICP, изменить источник, добавить срок актуальности. Расширяйте поток после того, как команда умеет объяснить типовые ошибки и контролировать их последствия.


