AI Agents in Sales: от помощника менеджера до управляемого workflow

ИИ-агент — не автономный продавец

В production ИИ-агент для продаж — это управляемый workflow с моделью в отдельных шагах. Он получает событие из CRM, собирает контекст, выбирает разрешённый инструмент, готовит результат и останавливается перед действием, которое требует решения человека. Цель — сократить рутину вокруг переговоров, а не скрыть весь процесс внутри LLM.

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

State machine и события CRM

Надёжный агент привязан к состояниям воронки: new lead, qualified, discovery, proposal, negotiation и won/lost. Переходы инициируются проверяемыми событиями — заполненной формой, звонком, письмом, оплатой или подтверждением менеджера. LLM может предложить переход, но системная логика проверяет обязательные поля и разрешения.

Каждый запуск получает deal_id, event_id и idempotency key. Workflow хранит текущий шаг, результат инструмента и причину остановки, поэтому его можно безопасно продолжить после сбоя. Это важнее длинной «памяти агента»: факты живут в CRM, а состояние исполнения — в оркестраторе.

Инструменты и память

Инструменты должны отражать бизнес-действия: get_deal, search_product_catalog, create_draft_email, add_note и schedule_task. Tool send_email следует отделить от create_draft_email и защищать более строгим подтверждением. Узкие схемы ограничивают выбор модели и упрощают аудит.

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

Approval, безопасность и наблюдаемость

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

Логируйте выбранный tool, аргументы после маскирования, результат, время, стоимость, версию prompt и решение пользователя. Алерты отслеживают циклы инструментов, рост отказов, ошибки CRM и необычное число действий на сделку. Лимит шагов и бюджет запуска останавливают runaway agent.

KPI i plan pilota

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

Пилот охватывает одну команду, один этап и понятный baseline. Сначала shadow mode генерирует рекомендации без изменений CRM, затем draft mode добавляет подтверждение, и только после этого автоматизируются действия низкого риска. Для каждого этапа нужны критерий выхода и блокирующие ошибки.

Разделение draft и send на уровне схемы инструмента

{
  "name": "create_draft_email",
  "annotations": { "mutating": false, "requiresApproval": false }
},
{
  "name": "send_email",
  "description": "Отправляет письмо клиенту — только после подтверждения менеджера",
  "annotations": { "mutating": true, "requiresApproval": true, "maxPerDealPerDay": 3 }
}

FAQ