AI-агент для обработки входящих заявок: настройка за 3 дня без программиста

В Solar Property в 2025 году входящих сообщений приходило 80–120 в сутки. Telegram — основной канал, плюс email и периодически WhatsApp. Менеджер успевал ответить примерно на 60% — остальные зависали до утра или следующего рабочего дня. После запуска агента в декабре 2025 года время первого ответа упало с 22 минут до 40 секунд, а процент обработанных заявок поднялся до 97%. Это данные из мониторинга за первые 90 дней, не слайд из питч-деки.

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

Гайд рассчитан на B2B-бизнес с потоком входящих от 30 до 500 в сутки: консалтинг, услуги, аренда, туризм, онлайн-сервисы. Если у вас интернет-магазин с 5 000 заказов в сутки — архитектура та же, но масштаб и требования к инфраструктуре другие.

Когда нужен агент на входящих — три условия

Агент на входящих — это не кнопочный чат-бот и не скрипт с if/else. Это система, которая читает любое входящее сообщение, определяет его тип и выполняет нужное действие: отвечает, создаёт задачу, эскалирует на менеджера. Главное отличие от чат-бота — агент работает с произвольным текстом, а не со структурированным выбором из меню.

Агент имеет смысл, когда одновременно выполняются три условия:

• Поток больше 20–30 входящих в сутки. Ниже этой отметки проще ответить вручную — агент избыточен и не окупится по времени настройки.
• Значительная часть запросов повторяется. «Сколько стоит», «когда освобождается», «как оплатить», «пришлите договор» — если такие вопросы составляют 40%+ входящих, агент возьмёт на себя всё это.
• Скорость первого ответа критична для бизнеса. В туризме, аренде, онлайн-сервисах клиент не ждёт больше 5–10 минут. В B2B с длинным циклом сделки — менее критично, но всё равно приятно.

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

Архитектура: четыре компонента, которые нужны всегда

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

Компонент 1: Webhook-приёмник

Это точка входа. Telegram, WhatsApp Business API, email (через Mailgun или Postmark) отправляют события на ваш URL. Приёмник получает событие, парсит его структуру и кладёт в очередь на дальнейшую обработку.

Минимальная реализация на Python с Flask — 30–40 строк. На n8n — один нод «Webhook» без единой строки кода. На Make (Integromat) — аналогично. Выбор платформы на этом уровне не принципиален: главное, что приёмник надёжно принимает события и не теряет их при пиковой нагрузке.

В Solar Property приёмник написан на Python и работает как systemd-сервис на VPS. За 6 месяцев работы — ни одного пропущенного события при потоке 3 000+ сообщений в месяц. Для старта n8n даст то же самое с меньшими трудозатратами.

Компонент 2: Классификатор

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

Простейший классификатор — это промпт в Claude Haiku или GPT-4o-mini:

Определи тип этого сообщения одним словом:
PRICE_INQUIRY / BOOKING_REQUEST / COMPLAINT / DOCUMENT_REQUEST / IRRELEVANT
Сообщение: {message}

Точность такого промпта на реальном входящем потоке — 93–95%. Это проверено на 3 000+ реальных сообщениях. Оставшиеся 5–7% — пограничные случаи, которые агент правильно эскалирует, а не пытается угадать с риском ошибиться.

Более развитый классификатор добавляет приоритет (HIGH / MEDIUM / LOW), извлекает именованные сущности (даты, суммы, имена клиентов), определяет язык сообщения. На Claude Haiku 4.5 вся эта логика занимает 1–2 секунды и стоит менее $0.001 за запрос — то есть меньше рубля на 100 классификаций.

Компонент 3: Обработчик и генерация ответа

На основе категории от классификатора обработчик выбирает действие. Логика простая:

• PRICE_INQUIRY → достать актуальные цены из базы данных → сгенерировать ответ с конкретными цифрами
• BOOKING_REQUEST → создать задачу в CRM или трекере → ответить «получили, свяжемся в течение 15 минут»
• COMPLAINT → немедленная эскалация + уведомление менеджера → ответить клиенту «передаём приоритетно»
• DOCUMENT_REQUEST → достать нужный документ из хранилища → отправить файл напрямую
• IRRELEVANT → проигнорировать или ответить «не совсем понял, уточните запрос»

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

Компонент 4: Эскалатор

Агент должен чётко знать, когда отступить и позвать человека. Эскалатор — это набор правил, при которых задача немедленно передаётся менеджеру:

• Классификатор уверен менее чем на 70% (низкий confidence score)
• Сообщение содержит ключевые слова жалобы, угрозы или конфликтного контекста
• Клиент получил 2 или более автоответа и написал снова — значит, не получил нужного
• Сумма потенциальной сделки выше установленного порога (в Solar Property — выше $2 000)

При эскалации агент выполняет три действия: (1) уведомляет менеджера с полным контекстом переписки, (2) отвечает клиенту «передаю нашему специалисту, ответит в ближайшее время», (3) помечает тред как требующий ручного внимания, чтобы агент его больше не обрабатывал.

Выбор стека: n8n, Python или облачный сервис

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

n8n self-hosted — оптимальный старт для большинства малых бизнесов. Разворачивается через Docker Compose за 20 минут, работает на VPS за €3.79/мес, имеет нативные ноды для Telegram, Gmail, HTTP Request, Claude API. Визуальный редактор позволяет собрать рабочий прототип за один день без единой строчки кода. Ограничение: если понадобится сложная логика с памятью между сессиями — придётся добавлять Python Function-ноды или переходить на кастомного агента.

Python + Flask — если у вас или в команде есть разработчик хотя бы уровня junior. Полная гибкость, лёгкая интеграция с PostgreSQL для хранения истории диалогов, никакой зависимости от внешней платформы. Примерный объём кода для рабочего агента: 200–300 строк на базовую версию. В Solar Property выбрали этот вариант из-за требований к хранению контекста и частых кастомных проверок.

Make (Integromat) или Zapier — если нужны конкретные интеграции, которых нет в n8n, или если команда категорически не хочет администрировать собственный сервер. Стоимость растёт пропорционально объёму операций: при 3 000+ входящих в месяц облачные тарифы становятся дороже, чем VPS с n8n.

Для прохождения через три дня этого гайда подойдёт любой вариант. Примеры дальше — для n8n и Python параллельно.

День 1: настройка webhook и тестовый приём событий

Первый день — исключительно инфраструктура. Никакой логики, никаких ответов. Только твёрдая уверенность, что события от мессенджеров доходят до сервера.

Выбор платформы. Для старта без кода — n8n (self-hosted бесплатно или n8n.cloud от $20/мес). Для тех, кто пишет код, — Python + Flask + ngrok для локального тестирования перед деплоем на VPS.

Настройка Telegram Webhook пошагово:

1. Создать бота через @BotFather — получить токен вида 7XXXXXXXXX:AAF...
2. Поднять сервер с HTTPS (Let's Encrypt — бесплатно, 15 минут; или Cloudflare Tunnel — 5 минут без открытых портов)
3. Зарегистрировать webhook командой POST https://api.telegram.org/bot{TOKEN}/setWebhook?url=https://your-server.com/webhook
4. Написать боту любое тестовое сообщение → убедиться, что JSON-событие появилось в логах сервера

Типичная проблема первого дня — SSL-сертификат. Telegram принимает только HTTPS. Если webhook не отвечает — проверьте, что сертификат валидный, порт 443 открыт и сервер возвращает статус 200 OK. Cloudflare Tunnel решает это автоматически, не требуя настройки сертификата вручную.

Итог первого дня: любое сообщение боту → лог на сервере с полным JSON-объектом события. Результат скромный на вид, но это твёрдый фундамент всей системы — без него второй и третий день невозможны.

Для email: настройте Mailgun Webhook или Postmark Inbound. Принцип тот же — разница только в формате JSON-события. Маршрутизация входящих писем через MX-запись домена на ваш endpoint настраивается за 20 минут. Для WhatsApp Business API — аналогично, но сначала нужно пройти верификацию Meta Business, которая занимает 2–5 рабочих дней.

День 2: классификатор и первые автоответы

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

Шаг 1: написать промпт классификатора на основе реальных данных.

Не копируйте чужой промпт. Возьмите 50–100 последних входящих сообщений именно из вашего бизнеса, вручную разметьте их по категориям. Это займёт час, но даст точность 90%+ с первой же версии. Промпт, обученный на реальных примерах из вашего контекста, в 2 раза точнее универсального шаблона из интернета.

Структура промпта классификатора для B2B-услуг:

Ты классификатор входящих сообщений для [название компании].
Определи категорию. Отвечай только одним словом.

PRICE — вопросы о стоимости, скидках, тарифах
SERVICE — уточнение деталей услуги
COMPLAINT — недовольство, жалоба, проблема
READY_TO_BUY — явная готовность купить прямо сейчас
OTHER — всё остальное

Сообщение: {message}

Шаг 2: подключить Claude API.

claude-haiku-4-5-20251001 — оптимальный выбор для классификации: скорость ответа 0.8–1.2 секунды, стоимость $0.0008 за тысячу токенов. claude-sonnet-4-6 — для генерации ответов, где нужно качество и точная передача тона бренда. API key получить на console.anthropic.com. При 100 входящих в день с полным циклом (классификация + генерация ответа) расходы составят менее $3 в месяц.

Шаг 3: написать контекстные промпты для генерации ответов.

На второй день не нужно покрывать всё. Нужно закрыть 2–3 самые частые категории. Остальные пусть идут в «передать менеджеру». Пример контекста для PRICE_INQUIRY:

Клиент спросил о ценах на услуги.
Данные:
- Базовый пакет: {price_basic} рублей в месяц
- Расширенный пакет: {price_premium} рублей в месяц
- Акция до {promo_date}: скидка {discount}%

Ответь конкретно, без лишних слов. Тон: деловой.
Не используй слово "выгодно".

Итог второго дня: агент читает входящие → классифицирует → отвечает на 3–5 типов запросов. Остальные логирует без ответа. Эскалация настраивается на третий день.

День 3: эскалация, мониторинг и первые 24 часа в боевом режиме

Третий день — защита от сбоев и передача управления системе.

Настройка эскалации на менеджера.

Самое важное — немедленные уведомления, когда агент не уверен или встречает конфликтный кейс. Реализация:

1. Создать отдельный Telegram-бот для внутренних уведомлений (чтобы не смешивать с клиентским ботом)
2. При эскалации — отправить менеджеру: категория + текст входящего + последние 5 сообщений диалога
3. Добавить кнопку «Взять в работу» — при нажатии тред помечается как «взят», агент его больше не трогает

В Solar Property этот механизм настраивали 2 часа на третий день. За 6 месяцев он отработал корректно в 99.3% случаев эскалаций.

Мониторинг: минимальный набор метрик.

На старте достаточно четырёх показателей:

• Количество входящих за 24 часа (по каналам отдельно: Telegram, email, WhatsApp)
• Процент обработанных автоматически vs. переданных на эскалацию
• Среднее время ответа — для автоматических и для эскалаций отдельно
• Ошибки классификатора: все случаи с confidence ниже 80%

Простейшая реализация — таблица в PostgreSQL + Python-скрипт, считающий метрики раз в час. Дашборд — даже Google Таблица с подключением к базе через Apps Script. В Solar Property на дашборд ушло 4 часа разработки. Сложный BI-инструмент не нужен.

Первые 24 часа в боевом режиме — обязательный ручной контроль.

Просматривайте каждый диалог первые сутки. Ищите случаи, где агент ответил неточно или не ответил вообще. Это не недоверие к системе — это калибровка, которая поднимает точность классификатора с 93% до 97%+ за первый месяц. После первых 48 часов снизьте частоту до ежедневной проверки спорных случаев.

Шесть ошибок, которые ломают агент на входящих

За 6 месяцев работы агента в Solar Property и трёх внедрений у клиентов один и тот же список ошибок повторялся в разных вариациях. Вот они.

Ошибка 1: жёсткие шаблоны ответов без генерации через LLM. «Спасибо за обращение! Стоимость услуги X — Y рублей.» Этот ответ сломается на любом нестандартном входе. LLM-генерация с контекстом гибче и не требует поддержки 20 разных шаблонов для каждого варианта вопроса.

Ошибка 2: агент не помнит предыдущих сообщений диалога. Если не хранить историю — агент задаёт одни и те же вопросы по кругу. Решение: хранить историю диалога в базе, подавать последние 8–10 сообщений как контекст в каждый запрос к LLM.

Ошибка 3: агент отвечает на всё подряд, включая «ок» и «👍». Не каждое сообщение требует ответа. Добавьте категорию SKIP и правило: не отвечать на сообщения короче 5 символов и на явные подтверждения предыдущего ответа.

Ошибка 4: нет fallback при ошибке Claude API. Anthropic и OpenAI недоступны 0.05–0.1% времени — редко, но случается. Без fallback-логики агент просто пропустит входящее. Минимум: при ошибке API — уведомить менеджера и отправить клиенту «Ответим в ближайшее время».

Ошибка 5: не логировать спорные классификации. Если не записывать случаи с низким confidence, улучшить промпт невозможно. Логируйте все случаи с confidence ниже 80%, раз в неделю разбирайте их — это главный источник роста точности системы.

Ошибка 6: запустить агент сразу на 100% трафика. Начните с 20–30% входящих. Остальные обрабатывайте параллельно вручную. Через 10–14 дней, когда уверены в системе, — переводите весь трафик. Это снижает риск испорченных отношений с клиентами из-за ранних ошибок агента.

Ошибка 7: не устанавливать максимальную длину очереди обработки. При внезапном росте входящих (акция, вирусный пост, утечка номера) очередь может переполниться и агент начнёт отвечать с задержкой 10–15 минут — хуже, чем вообще без агента. Ограничьте очередь: при длине больше 50 задач — переводить новые входящие сразу на «ответим в ближайшее время» без обработки через LLM. В Solar Property такой случай был один раз: февраль 2026, пост набрал охват и пришло 340 сообщений за 2 часа. Ограничение очереди сработало автоматически.

Что добавить после первых двух недель

Прототип из трёх дней — стартовая точка, не финальная система. После того как агент стабильно работает, вот что имеет смысл добавить в порядке приоритета.

Многоязычность. Если к вам пишут на нескольких языках — добавьте определение языка в классификатор и отдельные промпты для каждого. Claude переключается между русским, английским и индонезийским без потери качества ответа. В Solar Property это решило 15% входящих, которые агент раньше маркировал как IRRELEVANT — они просто писали по-английски, а не по-русски.

Обогащение контекстом из базы данных. Когда агент знает историю клиента — он отвечает точнее и персональнее. Реализация: поиск клиента по telegram_id или email в базе → подача релевантного контекста в промпт. Это поднимает конверсию из переписки в действие на 15–25%.

Sentiment analysis. Дополнительный промпт или встроенный в классификатор: определять эмоциональный тон сообщения. Нейтральный → стандартный ответ. Раздражённый → более мягкий тон плюс ранняя эскалация. В Solar Property это снизило число перерастания переписок в конфликты на 40%.

A/B тестирование формулировок ответов. Для PRICE_INQUIRY может быть 2–3 варианта ответа с разной подачей. Логируйте, какой вариант чаще приводит к следующему шагу — уточнению деталей, бронированию. Оптимизируйте по данным, не по ощущениям.

Интеграция с актуальными данными в реальном времени. Агент, который сам проверяет свободные даты в системе бронирований и отвечает актуальной информацией, ценнее агента, который отвечает «уточним у менеджера». В Solar Property подключение к базе данных бронирований сократило среднее время сделки с 48 часов до 6 часов.

Цифры: что даёт агент на реальном потоке за 6 месяцев

После 6 месяцев работы агента в Solar Property на входящих из Telegram и email результаты следующие:

• Время первого ответа: с 22 минут до 40 секунд в рабочее время; с «до утра» до 2 минут ночью
• Автоматически обработано без менеджера: 73% всех входящих
• Жалоб на долгий ответ от клиентов: было 8–12 в месяц, стало 0–1
• Время менеджера на входящих: было 3–4 часа в день, стало 40–60 минут только на эскалациях

Юрий Солар, Solar Property: «Агент не заменяет менеджера — он берёт на себя то, что менеджер ненавидит: сороковой одинаковый вопрос про цену за один день. После запуска агента менеджер занимается тем, что действительно требует человека.»

Если хочешь собрать такую же систему — в клубе «Solar — внутрянка» лежат AGENTS.md, prompt-шаблоны классификатора, готовый n8n-workflow для Telegram и Python-скрипт мониторинга с дашбордом. Всё из боевой системы Solar Property с реальными логами и комментариями, а не теория. Адаптируй под свой контекст. Клуб — от 2 500 ₽/мес.

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