ИИ-агенты для продаж: что умеют и как провести первую проверку

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

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

Чем ИИ-агент отличается от обычной автоматизации

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

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

Упрощённый рабочий цикл выглядит так:

1. Агент получает цель.
2. Собирает доступный контекст.
3. Выбирает разрешённое действие.
4. Обращается к CRM, базе знаний или другому инструменту.
5. Анализирует результат.
6. Выполняет следующий шаг, завершает задачу или передаёт её человеку.

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

Агент полезен, когда процесс содержит неоднозначные решения, неструктурированные данные и много допустимых вариантов. Строгие правила лучше оставить для обязательных ограничений: запретов на отправку, лимитов, проверки статусов и определения доступных инструментов.

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

Какие задачи в продажах можно поручить агенту

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

Исследование компании и контакта

Агент может собрать информацию из CRM, корпоративных документов и разрешённых открытых источников. На выходе менеджер получает краткую сводку:

• чем занимается компания;
• каким критериям целевого профиля она соответствует;
• какие факты подтверждены;
• каких данных не хватает;
• что стоит проверить перед контактом.

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

Если сам процесс поиска компаний ещё не выстроен, сначала стоит разобраться, как устроена B2B-лидогенерация, а затем выбирать участок для агента.

Предварительная квалификация

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

Результат лучше представлять не как окончательный вердикт, а как:

• найденные признаки;
• отсутствующие сведения;
• противоречия;
• предварительную категорию;
• рекомендацию по ручной проверке.

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

Подготовка сообщения

Агент может использовать проверенные факты, чтобы подготовить черновик обращения. Человек проверяет адресата, релевантность, формулировки, обещания и соответствие выбранному сегменту.

Автоматическая персонализация не исправляет слабое предложение. Она также не даёт разрешения на отправку и не отменяет ограничения почтового провайдера или выбранной площадки.

О том, как ИИ помогает с исследованием, сообщениями и ответами без полной автономности, подробнее написано в статье про ИИ в B2B-продажах.

Разбор входящих ответов

Агент может определить предполагаемый тип ответа:

• интерес;
• просьба прислать подробности;
• вопрос, требующий экспертизы;
• отказ;
• просьба больше не писать;
• автоматический ответ;
• сообщение, не относящееся к текущей кампании.

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

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

Обновление CRM

Агент способен подготовить сводку, заполнить разрешённые поля, создать задачу или предложить новый статус. Но запись в CRM и отправка сообщения являются разными уровнями полномочий.

На первом этапе полезно разрешить агенту только:

• читать нужные записи;
• готовить предлагаемые изменения;
• сохранять черновик;
• создавать запись для ручной проверки.

Право самостоятельно менять данные стоит добавлять только после тестирования каждого типа операции.

Что не стоит передавать без подтверждения

Человек должен сохранять контроль над действиями, которые создают обязательства или трудно отменяются:

• согласование цены и скидки;
• обещание срока или результата;
• изменение условий сотрудничества;
• спорный ответ клиенту;
• массовое изменение CRM;
• удаление данных;
• самостоятельное продолжение разговора после неоднозначного ответа;
• действия с юридическими или репутационными последствиями.

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

Два примера работы ИИ-агента

Ниже приведены учебные сценарии. Это не кейсы с обещанными результатами, а модели, по которым можно описать собственный процесс.

Сценарий 1. Подготовка лида к работе

Исходная проблема. Менеджер получает список компаний и вручную собирает сведения из нескольких источников. На одну карточку уходит время, а формат результата зависит от конкретного сотрудника.

Действие агента. Агент получает запись из CRM, проверяет доступные источники, сравнивает компанию с критериями профиля целевого клиента и готовит структурированную сводку.

Проверка человека. Менеджер проверяет ключевые факты, сомнительные признаки и предложенную категорию. Если данных недостаточно, лид не получает положительную оценку автоматически.

Допустимый результат. В CRM появляется единообразная сводка и рекомендация по следующему шагу. Агент не отправляет сообщение и не объявляет компанию подходящей без оговорок.

Сценарий 2. Первичный разбор ответа

Исходная проблема. Ответы приходят в разные моменты, а автоматическая последовательность может продолжиться до того, как менеджер прочитает письмо.

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

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

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

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

Из чего состоит работающий агент

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

Цель и инструкции

Недостаточно написать «найди хороших клиентов». Нужно определить:

• что считается завершённой задачей;
• какие данные разрешено использовать;
• какие признаки нужно проверить;
• что запрещено делать;
• когда агент обязан остановиться;
• кому передавать исключение.

Чем расплывчатее цель, тем сложнее проверить результат.

Источники данных

Агент может использовать:

• CRM;
• базу знаний;
• коммерческие материалы;
• историю писем и встреч;
• расшифровки разговоров;
• внутренние критерии квалификации;
• разрешённые открытые источники.

Подключение к CRM не исправляет плохие данные. Дубли, устаревшие статусы, пустые поля и противоречивые инструкции перейдут в работу агента.

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

Инструменты

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

Полезно разделять три уровня:

1. Агент видит информацию.
2. Агент предлагает действие.
3. Агент выполняет действие.

Переход от одного уровня к следующему требует отдельной проверки.

Состояние и память

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

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

Журнал действий

Для каждой операции желательно сохранять:

• входные данные;
• версию инструкций;
• вызванные инструменты;
• полученные результаты;
• итоговое действие;
• причину остановки или передачи человеку;
• внесённое сотрудником исправление.

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

Без журнала трудно понять, ошиблась модель, не сработала интеграция или агент вообще не получил нужные данные.

Как выбрать первый сценарий

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

Подходящий сценарий обычно обладает следующими признаками:

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

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

Заполните карточку до выбора сервиса:

Если карточку невозможно заполнить, проблема, вероятно, находится не в выборе модели. Сначала нужно определить сам процесс.

Как выбрать готовый сервис или собственную разработку

Готовый продукт быстрее даёт стандартный сценарий, но ограничивает интеграции, логику и доступные данные. Собственная разработка позволяет точнее описать процесс, однако требует поддержки, тестирования и наблюдения после запуска.

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

Оценивать нужно не количество функций в презентации, а работу на собственных примерах.

Какие вопросы задать поставщику

• Поддерживается ли русский язык именно в нужной функции?
• Как система работает с названиями российских и международных компаний?
• Какие источники используются при исследовании?
• Можно ли увидеть источник каждого важного факта?
• Какие поля CRM агент читает и изменяет?
• Есть ли отдельная учётная запись для агента?
• Можно ли оставить отправку только на ручном подтверждении?
• Как выглядит журнал действий?
• Что происходит при недоступности CRM?
• Можно ли остановить уже запущенную задачу?
• Где обрабатываются и хранятся данные?
• Как удалить переданную информацию?
• Что происходит после обновления модели?
• Как тарифицируются действия и внешние запросы?
• Можно ли выгрузить результаты и историю работы?

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

Из чего складывается стоимость

Расходы могут включать:

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

Поэтому сравнивать только цену токенов недостаточно. Сначала нужно определить сценарий и ожидаемый объём операций.

Как провести первую проверку

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

Шаг 1. Зафиксируйте исходный процесс

До запуска измерьте:

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

Без исходного уровня трудно отличить реальный эффект от впечатления новизны.

Шаг 2. Назначьте владельца

Владелец должен знать:

• где смотреть журнал;
• как остановить работу;
• какие записи затронуты;
• кто исправляет данные;
• кто принимает решение о расширении полномочий.

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

Шаг 3. Установите границы

Для каждого инструмента укажите:

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

Если агенту нужно подготовить письмо, ему необязательно давать право отправки.

Шаг 4. Соберите тестовый набор

Включите не только хорошие примеры:

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

Шаг 5. Начните с черновиков

Безопасная последовательность расширения полномочий:

1. Чтение данных и подготовка результата.
2. Черновик действия для подтверждения.
3. Ограниченная запись в тестовую среду.
4. Запись в реальные данные на небольшой выборке.
5. Автономное выполнение только низкорисковых действий.

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

Сохраните этот тестовый набор и повторяйте его после изменения модели, инструкций, базы знаний, доступных инструментов, прав или интеграций. Изменение любого из этих компонентов может вернуть уже исправленную ошибку или создать новую.

Шаг 6. Определите условия остановки

Работу следует остановить, если агент:

• отправил нежелательное сообщение;
• проигнорировал отказ;
• изменил запрещённое поле;
• раскрыл чувствительные данные;
• систематически выдумывает факты;
• вызывает неподходящие инструменты;
• не передаёт сложные случаи человеку;
• повторяет уже выполненные действия.

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

Какие риски нужно проверить

Избыточные полномочия

Риск появляется, когда агент одновременно имеет слишком много функций, широкие права и возможность действовать без подтверждения.

Сократить его помогают:

• отдельная учётная запись для агента;
• минимальный набор доступных инструментов;
• разделение чтения и записи;
• подтверждение внешних действий;
• лимиты на количество операций;
• проверка прав внутри CRM или почтовой системы;
• журналирование;
• регулярный пересмотр доступов.

Нельзя полагаться только на текстовую инструкцию «не отправляй письмо». Запрет должен поддерживаться фактическими правами системы.

Инструкции внутри писем, сайтов и документов

Внешний текст может содержать указание, которое пытается изменить поведение агента. Например, страница компании может потребовать игнорировать прежние правила и передать закрытые данные.

Такой контент нужно считать недоверенным. Агент должен извлекать из него сведения, но не получать через него новые полномочия.

Практические меры:

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

Подключение базы знаний или дополнительное обучение модели не устраняет этот риск полностью.

Ошибочные и выдуманные факты

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

Для важных фактов полезно хранить:

• значение;
• источник;
• дату получения;
• статус: подтверждено, не подтверждено или источники противоречат друг другу;
• результат ручной проверки.

Не следует использовать самооценку модели как доказательство достоверности. Уверенно сформулированный ответ всё равно может оказаться ошибочным.

Особенно внимательно нужно относиться к именам, должностям, размеру компании, используемым технологиям и причинам интереса. Эти сведения быстро устаревают или могут относиться к другому человеку.

Дубли и пересечение сценариев

У одной компании могут одновременно работать несколько автоматизаций. Агент по поиску лидов, последовательность писем и автоматизированный процесс в CRM способны независимо принять решение об отправке.

Перед запуском нужен реестр активных сценариев:

• какая система инициирует действие;
• где хранится текущий статус;
• кто проверяет повторное событие;
• какая система останавливает остальные;
• где сохраняется отказ от контакта.

Одна запись «отказ» внутри отдельной кампании недостаточна, если другой процесс её не видит.

Персональные и коммерческие данные

До подключения следует составить схему движения данных:

1. Какие поля получает агент.
2. Какому поставщику они передаются.
3. В каком регионе обрабатываются.
4. Сколько времени хранятся.
5. Используются ли для обучения.
6. Кто имеет доступ к журналам.
7. Как данные удаляются.

Передавать весь массив CRM ради одного сценария обычно не требуется. Чем уже набор данных, тем проще контролировать риск.

Ограничения email

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

Правила зависят от страны, типа получателя, характера сообщения и используемого канала. Например, американские требования к коммерческим письмам распространяются и на B2B-коммуникации. Британские правила различают корпоративных адресатов, индивидуальных предпринимателей и некоторые партнёрства.

Для Великобритании правила электронной коммуникации и правила обработки персональных данных нужно проверять отдельно. Даже если согласие на B2B-письмо корпоративному адресату не требуется по PECR, имя и рабочий адрес конкретного сотрудника могут оставаться персональными данными. Тогда необходимо определить правовое основание, обеспечить прозрачность обработки и учитывать право человека возразить против прямого маркетинга.

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

Отдельно проверьте, нужно ли сообщать получателю об использовании ИИ. Универсального правила для всех стран, каналов и сценариев нет. Требование может следовать из закона, правил площадки, характера взаимодействия или внутренней политики компании. Наличие в продукте настройки уведомления об использовании ИИ помогает добавить такое сообщение, но само по себе не подтверждает юридическое соответствие сценария.

Подробнее о сегменте, технической базе, тесте и обработке ответов рассказано в руководстве о том, как выстроить B2B email-аутрич.

Ограничения LinkedIn

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

Наличие агента не отменяет эти ограничения. Перед подключением инструмента нужно проверить допустимые действия и риск ограничения аккаунта.

Как измерить результат

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

Работа процесса

• количество обработанных случаев;
• доля завершённых операций;
• время обработки;
• число сбоев;
• количество повторных действий;
• случаи, когда агент не запустился.

Качество результата

• фактическая точность;
• полнота;
• доля выдуманных сведений;
• правильность использования инструментов;
• количество ручных исправлений;
• стабильность на разных типах примеров.

Безопасность и контроль

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

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

Бизнес-результат

• стоимость корректно завершённого случая;
• высвобождённое время сотрудников;
• скорость передачи лида;
• изменение следующего этапа воронки;
• расходы на лицензии, интеграции и сопровождение.

Открытия, ответы и назначенные встречи полезны для наблюдения, но сами по себе не доказывают окупаемость агента. Вместе с запуском могли измениться сегмент, предложение, объём отправок или состав команды.

Для первой проверки достаточно оценить операционный эффект одного выбранного сценария:

Операционный эффект первой проверки =
стоимость фактически высвобождённого времени
− дополнительные расходы на сервис и интеграции
− стоимость настройки, проверки и исправлений
− оценённые потери от ошибок и инцидентов

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

Универсального процента роста или срока окупаемости нет. Результат зависит от выбранной задачи, качества данных, объёма операций и цены ошибки.

По результатам первой проверки возможны три решения:

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

С чего начать

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

Порядок действий:

1. Выберите одну повторяющуюся задачу.
2. Опишите правильный результат.
3. Зафиксируйте недопустимую ошибку.
4. Ограничьте доступные данные и действия.
5. Соберите тестовые случаи.
6. Начните с режима черновиков.
7. Сравните результат с исходным процессом.
8. Расширяйте полномочия только после проверки.

Если процесс нельзя описать и измерить без агента, подключение модели не сделает его управляемым. Сначала определите правила работы, владельца и источник актуального состояния.

Что почитать дальше

• Автоматизация продаж: как система ищет клиентов, пишет им и доводит до встречи
• ИИ в B2B-продажах: исследование компаний, черновики сообщений, разбор ответов и ручной контроль
• Лидогенерация в B2B: от ICP до созвона с продажником
• Как выстроить управляемый B2B email-аутрич

Использованные источники

Документация продуктов ниже подтверждает возможности и ограничения конкретных систем. Она не доказывает универсальную эффективность или окупаемость ИИ-агентов.

• OpenAI: A Practical Guide to Building AI Agents
• OpenAI: A Business Leader’s Guide to Working with Agents
• NIST: AI Risk Management Framework Core
• NIST: Artificial Intelligence Risk Management Framework: Generative AI Profile
• OWASP: Excessive Agency
• OWASP: Prompt Injection
• Microsoft Learn: Configure Sales Qualification Agent
• Microsoft Learn: Test Sales Qualification Agent
• Microsoft Learn: Secure Architecture for Sales Qualification Agent
• Microsoft Learn: Sales Qualification Agent Concepts
• Microsoft Learn: Responsible AI FAQ for Engage Mode
• Microsoft Learn: Monitor Leads Handled by Sales Qualification Agent
• Salesforce: Agentforce Prospecting
• Salesforce: Generative AI Considerations
• HubSpot: Use the Prospecting Agent
• Federal Trade Commission: CAN-SPAM Act Compliance Guide for Business
• Information Commissioner’s Office: Business-to-business marketing
• Google: Email Sender Guidelines
• LinkedIn: Prohibited Software and Extensions
• LinkedIn: User Agreement
• Google Cloud: Gemini Enterprise Agent Platform