AI-агент для квалификации лидов: обработать 200 заявок без менеджера

Входящая заявка в Telegram — в 9 из 10 малых бизнесов её обрабатывают так: менеджер видит сообщение через 20-40 минут, отвечает как умеет, ждёт реакции. Solar OS перестроил этот процесс: первый ответ уходит за 4-8 секунд, агент сам квалифицирует намерение клиента, и к моменту подключения человека уже знает тип задачи, срок и косвенный бюджет. Архитектура несложная: три агента, Claude API, Telegram webhook.

Это не про магию. Это про конкретную схему: listener принимает сообщение, classifier определяет намерение из 12 категорий, handler ведёт диалог по сценарию. Ниже — как это устроено, сколько стоит и как воспроизвести за 2 недели.

Почему ручная обработка заявок теряет деньги

Медленный первый ответ убивает сделку. Исследование InsideSales показало: скорость ответа в первые 5 минут повышает вероятность контакта в 10 раз по сравнению с ответом через час. В B2C (аренда, туризм, услуги) скорость ещё критичнее: клиент параллельно пишет трём-пяти конкурентам в одно время.

Три структурные причины, почему ручная обработка проигрывает:

• Менеджер занят или спит. Входящие приходят в 23:00, в воскресенье и в новогодние праздники. У агента нет нерабочих часов.
• Ответ непоследовательный. Один менеджер всегда спрашивает бюджет, другой — нет. CRM получает неструктурированные данные, отчёты не сходятся. Через три месяца никто не понимает, почему часть лидов неквалифицирована.
• Квалификация не происходит систематически. Менеджер тратит 40 минут на лида без бюджета, пока горячий клиент с деньгами ждёт ответа. Ни у кого нет времени разобраться, почему конверсия падает.

AI-агент снимает первые два пункта полностью. Третий — частично: агент собирает данные для квалификации, но финальное решение «берём или нет» всё равно принимает человек. Это правильно — агент не должен закрывать сделки самостоятельно.

Архитектура: три агента с разделением ответственности

В Solar OS входящий поток обрабатывает связка из трёх компонентов на базе Paperclip — multi-agent платформы поверх Claude API. Paperclip позволяет описывать поведение каждого агента через AGENTS.md файл и маршрутизировать задачи между агентами без ручного кода оркестрации. У каждого агента — одна роль, одна зона ответственности.

Listener — принимает и маршрутизирует

Telegram webhook → n8n → Listener-агент. Listener получает каждое входящее сообщение, определяет контекст (первый контакт или продолжение диалога) и отправляет задачу в очередь Classifier. Время работы: меньше одной секунды. Listener никогда не отвечает клиенту напрямую — только маршрутизирует.

Зачем отдельный агент для маршрутизации? Listener фильтрует системные события: служебные сообщения Telegram Bot API, пинги от мониторинга, сообщения от других ботов. Без этого слоя Classifier засоряется нерелевантным шумом и тратит токены впустую.

Разделение ролей критично: если посадить один агент на всё, он путает роли — пытается одновременно классифицировать, отвечать и вести диалог. Это производит непоследовательные ответы и сложные логи для отладки. Три отдельных агента — три чистых точки ответственности, три места для правки, если что-то идёт не так.

Classifier — определяет намерение

Classifier принимает текст сообщения и историю диалога (до 20 предыдущих сообщений) и возвращает структурированный JSON с полями: intent, urgency, topic, language. В Solar OS 12 категорий intent: от «интерес к клубу» до «жалоба», «партнёрство» и «спам».

Почему отдельный агент, а не просто промпт внутри Handler? Классификация с цепочкой рассуждений требует большего контекстного окна и стоит дороже по токенам. Вынося её в отдельный кэшированный шаг, платишь за классификацию только один раз на новый диалог. На потоке 200 диалогов в месяц это экономия около 30-40% от общих затрат на API.

Важная деталь: Classifier не требует Claude Opus — достаточно Sonnet. Задача структурированная и хорошо описывается через JSON schema в системном промпте. Opus оставляешь для Handler, который генерирует свободный текст ответа и должен звучать по-человечески.

Handler — ведёт диалог и квалифицирует

Handler получает результат от Classifier и выбирает сценарий из AGENTS.md. Он задаёт квалификационные вопросы, собирает данные (тип задачи, масштаб, срок, косвенный бюджет), при необходимости отправляет ссылку или передаёт живому менеджеру с готовым брифингом. Handler не пытается закрыть сделку самостоятельно — это ключевое ограничение, прописанное явно.

Первые 15 секунд: что происходит после сообщения клиента

Клиент пишет в Telegram: «Привет, хочу узнать про автоматизацию».

За 15 секунд происходит следующее:

1. Telegram доставляет webhook в n8n — 0.3 сек.
2. Listener идентифицирует контекст: первый контакт, язык RU — 0.8 сек.
3. Classifier определяет: intent interest_automation_general, urgency low — 2.1 сек.
4. Handler формирует ответ по шаблону «первый контакт / общий интерес» — 4.7 сек.
5. Сообщение отправлено в Telegram — итого 5.2 сек с момента входящего.

Клиент получает живой, небюрократический ответ — не «вы попали в очередь ожидания». Тон Handler настроен как у умного коллеги, без шаблонных «Здравствуйте! Спасибо за обращение в нашу компанию!».

Между первым ответом и квалифицированной передачей менеджеру — от 5 до 15 минут диалога. Если клиент пишет развёрнуто — Handler квалифицирует за 3-4 обмена. Если односложно — за 6-8. В обоих случаях менеджер получает структурированный бриф, а не сырую историю переписки.

Четыре квалификационных вопроса: что и зачем спрашивает агент

За 3-5 обменов репликами Handler собирает структуру, нужную для передачи:

Прямой вопрос про бюджет агент не задаёт — это отталкивает. Вопрос про «готовый инструмент или кастом» квалифицирует косвенно: клиент, которому нужно «что-то готовое за 3000 рублей», и клиент с запросом «кастом под нашу CRM» — принципиально разные сделки с разными бюджетами (от 10 000 до 500 000 рублей — разница огромная).

После квалификации Handler автоматически формирует бриф: «Лид: Сергей, интерес к автоматизации Telegram-бота для записи клиентов. Команда 3 человека. Старт в течение месяца. Хочет кастом. Готов к созвону.» Менеджер подключается с контекстом.

AGENTS.md как инструкция для агента-продавца

AGENTS.md — документ поведения агента. Не системный промпт в коде, а отдельный текстовый файл, который описывает роль, тон, сценарий и стоп-сигналы. Единственное место, которое меняешь при настройке поведения — код при этом не трогается.

Для Sales Handler в Solar OS структура выглядит так:

# Sales Handler — входящие лиды

## Роль
Первый контакт для входящих. Задача: квалифицировать намерение
и передать данные менеджеру. НЕ продавать. НЕ называть цены
без согласования с Юрием.

## Тон
Живой, прямой, без корпоративных штампов. Как умный коллега,
а не скрипт колл-центра. Конкретно, с примерами, без воды.

## Квалификационный сценарий (строго по порядку)
1. Уточни тип задачи: что делается руками, что болит.
2. Узнай масштаб: сколько человек вовлечено.
3. Спроси про срок.
4. Квалифицируй бюджет косвенно: готовый инструмент или кастом.
5. Предложи созвон с конкретным временным слотом.

## Стоп-сигналы
- Клиент спрашивает цену → «Уточню у коллеги, пришлю до вечера».
- Клиент упоминает конкурентов → не критикуй, задай вопрос про боль.
- Клиент агрессивен → немедленная передача менеджеру.
- Клиент просит гарантии → честный ответ: гарантий нет, есть кейсы.

Это реальный фрагмент из рабочего AGENTS.md Solar OS. Агент читает его как системный контекст и следует ему. Изменить поведение агента — значит отредактировать текстовый файл. Код агента не меняется неделями.

«Юрий Солар, основатель Solar OS: AGENTS.md — единственный способ управлять агентом так, чтобы через три месяца сам понимал, почему он ведёт себя именно так. Без документа агент становится чёрным ящиком, который никто не решается трогать.»

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

Как агент работает с типичными возражениями клиента

Квалификационный диалог почти всегда натыкается на одни и те же возражения. В Solar OS под каждое — отдельная секция в AGENTS.md Handler с чётким сценарием ответа.

«Мне нужно подумать» — самое частое. Handler не давит: «Понятно. Чтобы не тратить ваше время потом, скажите — что именно хотите обдумать? Если это технический вопрос, я могу сразу ответить. Если по деньгам — это к коллеге, я не называю цены.» Такой ответ возвращает диалог в конкретику, не ставя клиента в тупик.

«Сколько это стоит?» — Handler отвечает честно: «Цены называю только коллега, потому что каждый проект считается индивидуально. Могу попросить его написать вам до вечера — вас такой формат устроит?» Агент не придумывает цифры и не уклоняется — он переводит вопрос в конкретное следующее действие.

«У нас уже есть CRM / мы пробовали автоматизацию» — Handler задаёт вопрос: «Что именно пробовали и что не устроило?» Это не возражение, а квалификационный сигнал. Клиент с опытом неудачной автоматизации — другой профиль: у него сформированы конкретные требования и завышенный скептицизм. Менеджер получает эту информацию в брифе и готовится к другому разговору.

«Мы небольшая компания, нам это не нужно» — Handler не спорит: «Когда компания маленькая, время основателя ценнее всего. Какие задачи сейчас отнимают больше всего вашего времени?» Если ответ есть — диалог продолжается. Если нет — это не целевой лид, и Handler корректно завершает диалог без потери времени ни с чьей стороны.

Все четыре сценария написаны в AGENTS.md Handler явно — как если бы ты инструктировал нового менеджера перед первым рабочим днём. Агент не «додумывает» — он следует документу. Поэтому ответы последовательны независимо от времени суток и настроения.

Мониторинг и отладка в первые 30 дней

В Solar OS мониторинг устроен так: все диалоги Handler пишутся в базу данных с полями intent_classified, handoff_triggered, handoff_time_minutes, manager_override. Каждое утро автоматический дайджест показывает: сколько диалогов прошли полный цикл, сколько потребовали ручного вмешательства и почему.

На первой неделе типичная картина: 20-30% диалогов требуют корректировки. К концу второй недели — 5-8%. Это нормально. Именно поэтому первые две недели обязателен ручной просмотр каждого диалога.

Три сигнала, что AGENTS.md нужно переписывать:

• Агент задаёт квалификационный вопрос 3 раза подряд без продвижения — сценарий не закрывает этот тип клиента.
• Клиент прямо пишет «ты бот?» — тон недостаточно живой, нужно переработать раздел тона в AGENTS.md.
• Handoff происходит без заполненных полей брифа — Handler не собрал нужные данные, сценарий квалификации неполный.

Каждый из этих сигналов — конкретная правка в AGENTS.md в тот же день. Не «разберёмся потом», а немедленно: агент ошибается на реальных клиентах прямо сейчас.

Каналы: Telegram не единственный вариант

Трёхагентная схема не привязана к Telegram. В Solar OS те же агенты параллельно обрабатывают входящие из нескольких источников:

• Telegram Bot API — основной канал. Webhook, простая авторизация, хорошая доставка сообщений.
• Instagram Direct — через Instagram Messaging API. Требует верифицированного Business аккаунта, зато аудитория другая.
• WhatsApp Business API — через официальных партнёров (360dialog, WATI). Критичен там, где аудитория общается именно в WhatsApp.
• Форма на сайте — webhook из формы на сайте → тот же n8n → тот же Classifier. Источник другой, обработка идентичная.

Все источники попадают в единую очередь Classifier. Менеджер в брифе видит поле source — аналитика по каналам без отдельных таблиц. Добавить новый канал в работающую систему — один день: настройка webhook + маппинг source в Listener. AGENTS.md Handler не меняется.

Когда AI-квалификация не работает

Длинный B2B-цикл с несколькими ЛПР. Если решение принимают четыре человека в течение шести месяцев — агент квалифицирует первичный интерес, но дальше нужен живой менеджер. Автоматика хороша на входе воронки.

Уникальный продукт без аналогов. Если клиент запрашивает интеграцию нестандартной ERP через нестандартный протокол — агент быстро выйдет за пределы компетенции. Базовые вещи спросит, техническую оценку делает только человек.

Малый поток — меньше 10 заявок в неделю. Проблема в лидогенерации, не в скорости обработки. Автоматизировать квалификацию при таком потоке — оптимизировать не то место.

Как запустить: минимальный стек и 14 дней

Дни 1-3: аудит реальных диалогов. Берёшь последние 50-100 входящих из Telegram и классифицируешь вручную. Какие намерения встречаются чаще всего? Какие вопросы задаёт менеджер при квалификации? Без этого аудита AGENTS.md будет написан «из головы» и не будет работать на реальных клиентах.

Дни 4-7: написание AGENTS.md для трёх агентов. Промпт Listener и Classifier — по 300-500 слов. Промпт Handler — 1500-2500 слов: роль, тон, квалификационный сценарий, стоп-сигналы, примеры ответов. Первую версию пишешь сам, потом тестируешь на примерах из аудита.

Дни 8-10: техническая интеграция. Telegram Bot API + n8n + Claude API. В n8n схема занимает 7-9 нод. На Python — 200-300 строк кода, один рабочий день. Для Classifier обязательно используй prompt caching — сокращает latency и снижает затраты на 40-60%.

Дни 11-14: тестирование и первая калибровка. Прогоняешь 20-30 сценариев вручную: стандартный лид, агрессивный клиент, спам, нестандартный запрос. Фиксируешь ошибки, правишь AGENTS.md. К четырнадцатому дню система готова к реальным лидам.

Затраты: Claude API Sonnet — 2-5 USD/мес на 200 диалогов при кэшировании. n8n self-hosted — бесплатно (VPS от 5 USD/мес). Telegram Bot API — бесплатно. Разработка кастомной версии — 20-40 часов.

Что меняется в операционке после запуска

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

В Solar OS после перехода на трёхагентную схему время от первого сообщения до квалифицированной передачи менеджеру сократилось с 6-8 часов до 15-20 минут. Менеджер подключается к готовым диалогам — без потери контекста и без «извините, а кто вы и откуда о нас узнали?».

Это не замена продаж — это очистка воронки от шума. Менеджер тратит время на квалифицированных лидов, а не на всех подряд. Конверсия из первого контакта в назначенный созвон растёт — не потому что агент «лучше продаёт», а потому что скорость первого ответа и качество брифинга стали принципиально другими.

Полная система — AGENTS.md для Listener, Classifier и Handler, n8n-схема с вебхуком, примеры реальных диалогов из Solar OS и шаблон мониторинговой таблицы — в клубе «Solar — внутрянка». Там я выкладываю артефакты из своей рабочей системы: бери и адаптируй под свой бизнес. От 2 500 ₽/мес: https://4bos.ru/inside/

Если нужна постановка под ключ — это отдельная история. Но сначала клуб: там поймёшь, что именно нужно тебе, а не то, что я предложу в КП. Больше по теме AI-агентов — в кейсе Solar Property и статье про штаб из 18 агентов.

Что делать с лидами, которые агент не смог квалифицировать

Примерно 5-10% диалогов выпадают за пределы сценариев Handler — слишком нестандартный запрос, клиент переключается между темами, сообщение на иностранном языке или откровенный спам с имитацией интереса. Для каждого из этих случаев нужен явный путь в AGENTS.md, иначе Handler «зависнет» в петле уточняющих вопросов.

В Solar OS три варианта выхода из нестандартного диалога:

• Escalate to human. Если Handler не может однозначно классифицировать намерение за 3 итерации — флаг escalation_required: true, сообщение менеджеру: «Непонятный диалог, нужен живой взгляд», история чата приложена. Менеджер подключается и ведёт дальше сам.
• Soft close. Если клиент очевидно не целевой (спрашивает про что-то, чем Solar не занимается) — Handler вежливо завершает диалог: «Похоже, мы занимаемся немного другим, но могу порекомендовать направление, куда смотреть». Нет агрессии, нет потери времени.
• Park and wait. Клиент ответил «подумаю» и замолчал. Handler ставит задачу на follow-up через 3 дня: автоматическое напоминание «Вы интересовались автоматизацией — удалось разобраться с вопросом?» Один раз, не более. Без агрессивного follow-up.

Все три сценария прописаны явно в AGENTS.md с конкретными условиями триггера. Агент не «решает сам» — он следует документу. Это убирает непредсказуемые поведения в граничных случаях, которые чаще всего и создают плохой опыт для клиента.

После 30 дней работы системы анализируй, какой процент диалогов попадает в каждый из трёх сценариев. Если escalation_required стабильно выше 15% — значит Classifier плохо покрывает реальные типы входящих и нужна ревизия списка intent с аудитом новых диалогов.

Отдельный момент — интеграция с CRM. В Solar OS квалифицированный бриф автоматически создаёт карточку лида в Notion через n8n: поля заполнены, источник указан, время первого контакта зафиксировано. Менеджер открывает CRM и видит очередь из готовых карточек, а не пустые поля, которые нужно заполнять после каждого звонка. Это 10-15 минут экономии на каждом лиде — умножь на 30 лидов в месяц и получишь 5-7 часов, которые менеджер тратил на рутину вместо продаж.