В большинстве отделов продаж начинать нужно с AI-помощника: он собирает контекст, предлагает следующий шаг и готовит черновики, но оставляет решение человеку. AI-менеджер оправдан только для узкого повторяемого процесса, где заранее определены разрешённые действия, лимиты, критерии передачи сотруднику и способ остановки.
Название продукта почти ничего не говорит об уровне автономности. Один сервис под словом «агент» может лишь подготовить письмо, другой — самостоятельно выбрать лид, отправить серию сообщений, изменить статус в CRM и передать заинтересованного клиента менеджеру.
Поэтому сравнивать нужно не интерфейсы и не обещания поставщиков, а полномочия системы в конкретном бизнес-процессе.
Что это меняет для менеджера
AI-помощник анализирует данные и помогает сотруднику: делает резюме сделки, ищет факты, предлагает формулировку, создаёт черновик задачи или письма. AI-менеджер получает право выполнять часть процесса без отдельного подтверждения каждого шага: например, исследовать входящие лиды, отправлять допустимый первый контакт, вести ограниченный follow-up и передавать диалог человеку по заданным признакам.
Практическое правило выбора выглядит так:
- если контекст неполный, решение зависит от переговоров, а ошибка может испортить отношения с клиентом — используйте помощника;
- если шаг повторяемый, результат наблюдаем, действие обратимо, а исключения можно распознать — добавляйте выполнение после подтверждения;
- если процесс стабилен, права ограничены, лимиты измеримы и есть надёжный handoff — допускайте автономную работу внутри этого контура.
Это не три разных продукта, а три режима одной архитектуры. Правильная система позволяет повышать автономность постепенно, не переписывая интеграции и не теряя журнал решений.
Как должна двигаться заявка
Продажа состоит не из одной задачи «пообщаться с клиентом». А из цепочки состояний: появился сигнал, собран контекст, определён следующий шаг, подготовлено действие, получено подтверждение, выполнена операция, зафиксирован результат. На каждом переходе отличаются цена ошибки, доступные данные и ответственный сотрудник.
До выбора модели опишите один сценарий на уровне событий. Например: новая заявка пришла с сайта. Контакт сопоставлен с компанией. Обязательные поля проверены. Компания оценена по целевому профилю. Подготовлено первое письмо. Письмо отправлено. Ответ классифицирован. Заинтересованный лид передан менеджеру.
Формулировка «AI обрабатывает лиды» скрывает все эти решения и не годится как техническое задание.
Для каждого перехода нужны пять атрибутов:
- вход: какие данные и в каком состоянии запускают шаг;
- решение: что именно система определяет или предлагает;
- действие: какая запись, сообщение или задача может появиться;
- контроль: кто подтверждает результат и какие правила нельзя нарушать;
- исключение: куда направляется кейс при нехватке данных, конфликте или сбое.
Такой разбор сразу показывает, где достаточно правил, где полезна языковая модель, а где требуется человеческое решение. Он также отделяет демонстрацию от production: красивый ответ в чате ещё не означает, что система умеет безопасно завершать бизнес-операцию.
Режим 1. Только рекомендации
В этом режиме AI не меняет бизнес-состояние. Он собирает историю контактов, выделяет недостающие данные, предлагает следующий шаг, формирует резюме встречи или черновик сообщения. Менеджер решает, использовать ли рекомендацию, редактирует её и сам выполняет действие.
Такой вариант подходит для старта, потому что позволяет проверить полезность на реальном потоке без высокой цены ошибки. Команда видит, где системе не хватает контекста, какие подсказки принимаются, сколько времени уходит на проверку и какие типы рекомендаций регулярно отклоняются.
Чтобы помощник не превратился в ещё одно окно с текстом, результат должен быть связан с рабочим объектом. Рекомендация по сделке хранит ссылку на исходные письма, встречи и поля CRM. Черновик задачи содержит срок, владельца и ожидаемый результат. Резюме показывает, какие утверждения взяты из фактов, а какие являются выводом модели.
Режим рекомендаций стоит выбирать, когда:
- сделки нестандартны и требуют переговорной стратегии;
- данные распределены по разным системам и пока ненадёжны;
- команда только формирует единые правила работы;
- ошибка может создать юридическое, репутационное или финансовое обязательство;
- нужно сначала собрать набор размеченных решений для последующих тестов.
Ограничение режима очевидно: сотрудник остаётся узким местом. Если рекомендаций много, а подтверждение не встроено в CRM, система создаёт дополнительную очередь, а не сокращает цикл.
Режим 2. Действия после подтверждения
Следующий уровень — AI готовит конкретную операцию, но выполняет её только после явного согласия уполномоченного пользователя. Это может быть отправка письма, создание задачи, изменение стадии, постановка встречи или заполнение полей CRM.
Подтверждение должно показывать не только кнопку «Применить». Но и последствия: кому уйдёт сообщение, какие поля изменятся, почему выбран этот шаг, какие факты использованы и что произойдёт при повторном нажатии. Для массовых операций нужен предварительный список объектов, выборка исключений и итоговый отчёт.
Этот режим полезен, когда решение уже достаточно стандартизировано, но цена ошибки ещё не позволяет убрать человека. Он сокращает ручной ввод и переключение между системами, сохраняя ответственность у сотрудника.
Особенно хорошо работают обратимые действия: создать черновик, назначить внутреннюю задачу, добавить тег, запланировать напоминание.
Главная техническая деталь — идемпотентность. Повтор события, перезагрузка страницы или повторное подтверждение не должны создавать второе письмо или дублирующую задачу. Каждая операция получает стабильный ключ, состояние выполнения и запись о результате.
Режим 3. Автономная работа в ограниченном контуре
AI-менеджер не должен означать «модель может делать всё, что умеет сотрудник». Production-контур задаётся белым списком действий, сегментом клиентов, каналом, частотными лимитами, бюджетом, рабочим временем, доступными источниками знаний и условиями немедленной передачи человеку.
Практический кейс продаж · Flow AI. Flow AI построила голосовой AI-интерфейс для outreach риелторов: пользователь задаёт кампанию естественной речью, а workflow уже сам проверяет opt-in и требования 10DLC/CAN-SPAM, получает данные, генерирует сообщения, отправляет их и логирует действия. То, что раньше занимало 3–5 часов ручной работы, в кейсе выполняется менее чем за минуту. Что я бы забрала в работу: практическая граница видна хорошо: AI может быть удобным «менеджером интерфейса», но право на реальные действия остаётся у workflow с policy-проверками. Источник: n8n ↗
Подходящий автономный сценарий имеет стабильный вход и ограниченный набор исходов. Например, агент может обрабатывать только входящие лиды из определённой формы, использовать утверждённую базу знаний, отправлять не более двух сообщений, не обсуждать индивидуальные условия и передавать диалог человеку при положительном намерении, вопросе вне базы или признаке недовольства.
Автономность следует отменять, если:
- система регулярно встречает новые классы исключений;
- результат нельзя однозначно проверить по данным;
- клиент ожидает персональных договорённостей;
- ошибка необратима или создаёт обязательство;
- нет владельца, который наблюдает метрики и разбирает инциденты.
Матрица выбора модели
Для выбора режима оцените каждый шаг процесса по двум главным осям: повторяемость решения и цена ошибки. Затем добавьте качество данных и обратимость действия.
| Характеристика шага | Рекомендация | Пример |
|---|---|---|
| Низкая повторяемость, высокая цена ошибки | Только помощник | Переговоры об индивидуальных условиях, ответ на конфликт |
| Средняя повторяемость, действие проверяемо | Выполнение после подтверждения | Письмо по утверждённому контексту, смена стадии, задача |
| Высокая повторяемость, низкая цена ошибки | Ограниченная автономность | Исследование лида, допустимый первый контакт, маршрутизация |
| Данные неполны или противоречат друг другу | Уточнение или ручная очередь | Не найден владелец сделки, расходятся реквизиты компании |
Не усредняйте оценку по всему процессу. Один и тот же AI может автономно обогащать карточку компании, просить подтверждение перед отправкой письма и только рекомендовать стратегию по крупной сделке.
Какие процессы подходят для AI-менеджера
Лучшие кандидаты находятся до и после сложного человеческого решения, а не внутри него. Система может собирать контекст до звонка, поддерживать дисциплину follow-up, проверять полноту CRM и контролировать передачу между ролями.
Хорошие кандидаты
- исследование компании и сбор подтверждённых фактов из разрешённых источников;
- первичная проверка соответствия целевому профилю;
- подготовка персонализированного черновика по утверждённому шаблону;
- напоминание о просроченном обязательстве и создание внутренней задачи;
- классификация ответа и передача заинтересованного лида правильной команде;
- контроль обязательных полей и обнаружение конфликтов в CRM;
- подготовка резюме сделки и списка рисков перед встречей.
Слабые кандидаты
- обсуждение цены и исключительных условий без фиксированных полномочий;
- обещание сроков, ресурсов или юридических условий от имени компании;
- разрешение претензии, где важны эмпатия и ответственность руководителя;
- выбор стратегии для крупной сделки на основании неполных данных;
- массовый outreach без ограничений частоты, согласий и контроля качества.
Если процесс не описан, внедрение автономного агента обычно лишь ускоряет существующий хаос. Сначала устраните дубли, определите владельцев, нормализуйте статусы и согласуйте критерии передачи.
Как я связываю событие со следующим шагом
Надёжная система разделяет контекст, решение и действие. Источники — CRM, почта, календарь, телефония и база знаний — передают события в слой нормализации.
Он сопоставляет клиента, проверяет обязательные поля и формирует версионированный контекст. AI-компонент создаёт рекомендацию или кандидата действия, но не получает прямое право произвольно менять внешние системы.
Между решением и исполнением находится policy engine. Он проверяет тип операции, роль, сегмент, канал, лимит, согласие, время и риск. Для режима помощника результат направляется в интерфейс сотрудника.
Для подтверждаемого режима создаётся preview операции. Для автономного режима разрешённая команда попадает в исполнитель с идемпотентным ключом.
После каждого шага журнал сохраняет входные факты, версию инструкции, результат модели, сработавшие правила, пользователя или агента, фактический ответ интеграции и следующий статус. Секреты внешних систем остаются в коннекторах. Модель получает только необходимые данные. Права агента минимальны и отделены от прав администратора.
Обязательные компоненты:
- реестр состояний процесса и допустимых переходов;
- слой получения и нормализации контекста;
- модель или набор моделей для ограниченных задач;
- policy engine с лимитами и правилами доступа;
- очередь подтверждений и human handoff;
- идемпотентный исполнитель действий;
- журнал, мониторинг, бюджет и kill switch;
- набор эталонных кейсов для регрессионной проверки.
Что я бы проверила на плохом сценарии
Основной риск — не отдельная неточная фраза, а неконтролируемое изменение бизнес-состояния. Ошибочный черновик можно исправить. Повторно отправленное письмо, неверно закрытая сделка или обещанная скидка уже влияют на клиента и отчётность.
| Риск | Как проявляется | Контроль |
|---|---|---|
| Недостаточный контекст | Рекомендация не учитывает встречу или договорённость | Проверка свежести, обязательные источники, отказ при пробеле |
| Размытые полномочия | AI выполняет действие, которое команда считала советом | Матрица прав по типу операции и явный preview |
| Дублирование | Повтор события создаёт второе письмо или задачу | Идемпотентный ключ и журнал состояния |
| Неверная эскалация | Сложный кейс продолжает обрабатываться автоматически | Набор триггеров handoff и ручная кнопка остановки |
| Утечка данных | В контекст попадают лишние записи или секреты | Минимальные права, фильтрация полей, изоляция коннекторов |
| Скрытый рост расходов | Длинный контекст и повторные вызовы используются для простых задач | Маршрутизация, кеширование, лимиты и стоимость на операцию |
Fallback проектируют до запуска. Система должна уметь остановить новую обработку, сохранить уже собранные данные, пометить частично выполненную операцию, назначить владельца и дать безопасный способ повторить шаг. Неизвестный класс ответа направляется человеку, а не маскируется под уверенный результат.
В продажах я отдельно сверяюсь с NIST AI Risk Management Framework: он предлагает рассматривать управление риском на всём жизненном цикле через функции Govern, Map, Measure и Manage. Для отдела продаж это означает: назначить ответственность, описать контекст применения, измерять качество по реальным сценариям и иметь управляемую реакцию на отклонение.
Стоимость: сравнивайте операцию, а не тариф модели
Полная стоимость включает интеграции, очистку данных, вызовы моделей, хранение контекста, проверку человеком, поддержку исключений, мониторинг и цену ошибки. Автономный режим может сократить ручную работу в нормальном потоке, но потребует более дорогих контролей и сопровождения.
Для расчёта используйте стоимость одного завершённого корректного результата:
стоимость результата = (инфраструктура + AI + поддержка + ручная проверка + исправление ошибок) / число корректно завершённых операций
Расчётный пример, не отраслевой benchmark. Допустим, отдел обрабатывает 4 000 однотипных лидов в месяц. Помощник требует в среднем 90 секунд проверки, автономный контур оставляет 20% кейсов человеку по 3 минуты, а 2% требуют дополнительного разбора по 10 минут. При стоимости рабочего часа 1 200 ₽ ручная часть составит: для помощника 4 000 × 1,5 мин × 20 ₽ = 120 000 ₽; для ограниченного агента 800 × 3 мин × 20 ₽ + 80 × 10 мин × 20 ₽ = 64 000 ₽. К этой разнице нужно добавить реальную стоимость платформы, разработки, эксплуатации и ожидаемого ущерба от ошибок. Подставлять следует собственные данные.
Переход к автономности экономически оправдан, когда объём и повторяемость действительно компенсируют стоимость контролей. Для редких сложных сделок помощник часто дешевле, потому что не требует строить полноценный исполнительный контур.
Как понять, что продажи реально ускорились
Сначала зафиксируйте baseline на том же классе кейсов: время до первого действия, долю заполненных данных, долю пропущенных follow-up, конверсию между этапами, количество исправлений и стоимость операции. Затем сравнивайте режимы на одинаковых сегментах.
| Метрика | Что показывает | Ошибка интерпретации |
|---|---|---|
| Принятие рекомендаций | Полезность помощника для менеджера | Высокая доля не доказывает влияние на продажи |
| Время проверки | Реальную нагрузку human gate | Не учитывать последующее исправление |
| Доля автономного завершения | Покрытие разрешённого контура | Считать незамеченные ошибки успехом |
| Handoff rate | Как часто агент передаёт кейс человеку | Стремиться к минимуму любой ценой |
| Корректность действия | Соответствие правилам и ожидаемому outcome | Оценивать только качество текста |
| Стоимость корректной операции | Unit economics с учётом контроля | Считать только токены или лицензию |
| Инциденты и дубли | Операционный риск | Скрывать редкие дорогие ошибки средним значением |
Microsoft рекомендует отдельно тестировать выбор лидов, качество исследования, содержание писем, follow-up и handoff. Аналогичный набор нужен для собственной системы. Эталонная выборка должна включать нормальные, пограничные, конфликтные, повторные и недопустимые кейсы. После изменения модели, инструкции, источника данных или правила запускайте регрессионную проверку.
Что я бы поменяла сначала
- Выберите один процесс. Не начинайте с цели «заменить менеджера». Возьмите конкретный поток: исследование входящих лидов, подготовка follow-up или контроль полноты CRM.
- Опишите состояния и полномочия. Зафиксируйте входы, допустимые действия, владельцев, исключения и необратимые последствия.
- Соберите baseline и эталонный набор. Нужны реальные обезличенные кейсы с ожидаемым решением и причиной.
- Запустите режим рекомендаций. Измеряйте принятие, время проверки, пробелы данных и причины отклонения.
- Добавьте подтверждаемое действие. Начните с обратимой операции, preview и идемпотентного исполнения.
- Настройте наблюдаемость. Журнал, метрики, бюджет, алерты, очередь исключений и kill switch должны появиться до автономности.
- Откройте узкий автономный контур. Ограничьте сегмент, канал, частоту, время, тип действия и условия handoff.
- Расширяйте по классам кейсов. Каждый новый класс проходит отдельную проверку и имеет собственные критерии остановки.
Критерий готовности к следующему уровню — не «модель стала умнее». А подтверждённая стабильность процесса: система воспроизводимо выбирает допустимое действие, корректно отказывается при нехватке данных, не создаёт дубли, передаёт исключения нужной роли и даёт экономический эффект после учёта контроля.
Где команда чаще всего сомневается
Может ли AI-менеджер полностью заменить продавца?
В узком стандартизированном участке он может выполнять значительную часть операций. Но переговоры, ответственность за исключения и изменение коммерческих условий остаются у человека. Полезнее проектировать распределение ролей, чем обещать полную замену профессии.
С какого режима начинать небольшому бизнесу?
Обычно с помощника, встроенного в один рабочий процесс. Он быстрее показывает качество данных и реальную полезность. Автономность добавляют после накопления эталонных кейсов и появления понятного владельца контроля.
Обязательно ли менять CRM?
Нет, если CRM имеет API, webhooks или другой надёжный интеграционный слой. Важнее отделить контекст и policy engine от интерфейса конкретной системы. Иногда сначала нужно нормализовать стадии и обязательные поля в текущей CRM.
Что сильнее всего влияет на стоимость?
Не только модель. Большую долю могут составлять интеграции, подготовка данных, проверка, обработка исключений и сопровождение. Считайте стоимость корректно завершённой операции на собственном объёме.
Как понять, что автономность стала слишком широкой?
Сигналы — рост ручных исправлений, неизвестные классы исключений, жалобы, дубли, частые отмены действий, увеличение стоимости и невозможность воспроизвести решение по журналу. В таком случае контур сужают до последнего стабильного уровня.
Источники и методическая база
- Sales Qualification Agent overviewMicrosoft Learn
- Responsible AI FAQ about the Research-only mode of Sales Qualification AgentMicrosoft Learn
- Test the Sales Qualification AgentMicrosoft Learn
- Monitor leads handled by the Sales Qualification AgentMicrosoft Learn
- Welcome to Dynamics 365 SalesMicrosoft Learn
- Agentforce Lead Nurturing OverviewSalesforce Help
- Agentforce SDRSalesforce Help
- Set up and use the prospecting agentHubSpot Knowledge Base
- Artificial Intelligence Risk Management Framework (AI RMF 1.0)NIST
- NIST AI RMF PlaybookNIST
- Evaluation best practicesOpenAI
- How Flow AI built a voice-controlled real estate outreach engine on n8nn8n
