GitHub - gulnaz-bakinova/n8n-ai-sales-system: Production-ready AI Sales Agent for WhatsApp. Features: RAG (Supabase), Lead Scoring, Multi-modal pipeline, Batch Analytics, and strict Safety Guardrails. Built with n8n & Gemini.

1. Проблема (Challenge)

• Специфика холодной базы: ежедневные массовые рассылки генерируют шквал хаотичных ответов — от интереса до агрессии и голосовых сообщений.
• Выгорание продажников: менеджеры тратили часы на нецелевые ответы вместо звонков заинтересованным клиентам.
• Угроза потери WhatsApp-номера (Brand Safety): При холодных рассылках раздраженные клиенты жалуются на спам и блокируют номер — несколько жалоб приводили к полной блокировке номера компании.

2. Решение (Solution)

Совместно с фаундером и отделом продаж оцифрован скрипт и матрица возражений.

Разработано event-driven middleware на n8n: бот ведёт клиента по State Machine к целевому действию — регистрации.

При отклонении от сценария LLM (Gemini) автономно отрабатывает возражения через векторную БД (Supabase) и возвращает клиента в скрипт.

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

<aside>

3. Результат (Impact)

• Автономные конверсии: Система доводит целевых клиентов до конца скрипта (выдача ссылки и инструкций для регистрации), позволяя части лидов регистрироваться самостоятельно (Zero-touch sales).
• Качественная фильтрация: Менеджеры подключаются только к "теплым" лидам, которые задали сложный вопрос, с уже собранным контекстом (Lead Score и саммари запроса).
• Оптимизация воронки: Внедрен Batch-анализатор (AI Analyst) для ежедневного выявления точек провала в скрипте и автоматический Follow-up для молчащих лидов (T+24h). </aside>

4. Архитектура (Architecture)

5. Реализованные функции (Core Functions)

1. Гибридная машина состояний

   Жёсткая воронка Discovery → Education → Registration Link на основе stage_id. LLM возвращает системные коды (SEND_INITIAL_OFFER, MANAGER, TERMINATE_CONVERSATION), а не просто текст.

2. Агентное поведение и RAG

   При отклонении от скрипта ИИ автономно обращается к векторной БД (Tool "Objections") или генерирует ответ по Guardrails. Хендофф на менеджера — только если запрос вне компетенций ИИ или клиент явно просит человека.

3. Защита от банов

   При детекции агрессии или просьб "не писать" бот мгновенно отправляет прощание и ставит статус Do Not Contact. Это предотвращает дальнейшие фоллоу-апы и защищает аккаунт от теневого бана.

4. Мультимодальный конвейер

   Автоматическая конвертация голоса (Whisper) и vCard-контактов в единый текстовый контекст перед LLM.

5. Умная передача менеджеру

   Kill-Switch командой /stop физически блокирует ИИ для данного контакта.

<aside>

6. Надёжность и Эксплуатация (Reliability)

• Idempotency (Защита от дублей): Настроен шлюз проверки входящих вебхуков. messageId сверяется с базой processed_events. Дубли от ChatApp/провайдера мгновенно игнорируются (Drop) для предотвращения двойных ответов.
• Resilience (Отказоустойчивость): Для всех запросов к внешним API (Gemini, Supabase) настроен Exponential Backoff (3 попытки, 5 секунд ожидания) для защиты от таймаутов и HTTP 429 Rate Limits.
• Error Handling (Обработка ошибок): Внедрен паттерн Dead Letter Queue. Глобальный триггер (99_global_incident_handler) перехватывает падение любой ноды, пишет лог ошибки в базу и отправляет Debug-алерт в Telegram.
• Runbook & Ops (Руководство по эксплуатации): Разработан документ RUNBOOK.md с матрицей инцидентов (Edge Cases Handling Matrix) для быстрой реакции на сбои (падение LLM, лимиты Google API, дубли).
• Observability (Наблюдаемость и логирование): Структурированное логирование всех этапов в Google Sheets. События — в processed_events, сбои — в dead_letters с привязкой к execution_id. Каждый ответ ИИ сохраняет источник (rag_source) для мониторинга качества. </aside>

7. Интеграции и Данные (Integrations Specs)