Dragon Side
AI Front Desk
Assistant
AI-бот для первичной обработки заявок автоцентра: принимает обращения, определяет намерение клиента, собирает данные по автомобилю и услуге, хранит состояние диалога в PostgreSQL и передаёт менеджеру подготовленные заявки.
AI Automation Builder / Workflow Architect
Telegram Bot API / n8n / OpenAI / PostgreSQL
lead intake / state machine / handoff
Telegram MVP for automotive service
Входящие заявки
приходят
в свободной форме
Dragon Side работает с несколькими направлениями автоуслуг: детейлинг, мойка, кузовной ремонт, слесарка, чип-тюнинг, тюнинг, motorsport-проекты и реставрация. Клиенты пишут как удобно им, а не как удобно менеджеру.
В каждом обращении менеджеру нужно понять не только текст вопроса, но и контекст: какая услуга нужна, есть ли намерение записаться, какой автомобиль у клиента, хватает ли данных для заявки и нужно ли подключаться человеку.
Определить тип обращения: вопрос, заявка, консультация, отмена или перенос.
Собрать марку, модель, год, двигатель, VIN или госномер — если это нужно для услуги.
Получить имя и телефон, а не считать Telegram username полноценным контактом.
Не передавать менеджеру каждый вопрос как лид, если клиент ещё просто уточняет.
Не обещать точную цену, сроки или отмену записи без проверки менеджером.
Чат превращается
в ручной разбор
- менеджер сам уточняет данные;
- часть обращений приходит неполной;
- вопросы и заявки смешиваются;
- старый контекст легко теряется;
- handoff зависит от ручного внимания.
Бот готовит
структурированный лид
- определяет intent обращения;
- собирает нужные поля по услуге;
- помнит состояние диалога;
- задаёт уточняющие вопросы;
- передаёт менеджеру готовую заявку.
Сделать не “бота с GPT”, а первый слой приёмки: систему, которая принимает обращение, понимает намерение клиента, собирает данные, хранит состояние и передаёт человеку уже подготовленный контекст.
Свободный AI Agent
не должен быть
главным мозгом
На раннем подходе AI Agent сам вёл диалог, решал что спросить, когда передавать менеджеру и как помнить состояние. Для реальной приёмки заявок это оказалось слишком хрупко.
Telegram
→ AI Agent
→ Reply
Вся логика завязана на модель: она сама интерпретирует сообщение, сама решает следующий шаг и сама пытается удерживать контекст.
LLM
→ Scenario Engine
→ PostgreSQL
LLM работает как языковой слой. Бизнес-решения принимает сценарная логика, а состояние диалога хранится в базе данных.
Бот считал обычный вопрос готовой заявкой и слишком рано делал handoff.
Модель забывала уже собранные данные и могла задавать повторные вопросы.
Старые данные из прошлой заявки могли попадать в новый сценарий.
Бот мог отвечать менеджерам в группе так, будто это новые клиенты.
Language layer
Извлекает смысл из свободного текста, классифицирует intent, достаёт данные по авто, услуге и контакту, а также формулирует человеческий ответ.
Business brain
Решает, что делать дальше: уточнять услугу, просить контакт, подтверждать автомобиль, продолжать консультацию или передавать заявку менеджеру.
Source of truth
Хранит профиль клиента, автомобили, активную заявку, историю сообщений, handoff-статусы и завершённые обращения.
LLM отвечает за язык. Workflow отвечает за решения. PostgreSQL отвечает за память и состояние. Именно такое разделение делает бота управляемым, а не зависимым от одного большого промта.
Архитектура
разделяет язык,
логику и данные
Финальная схема устроена как управляемый workflow: Telegram принимает сообщение, n8n ведёт процесс, LLM извлекает смысл и пишет ответ, Scenario Engine принимает решения, а PostgreSQL хранит состояние диалога.
Бот не полагается на один большой промт. Каждый слой отвечает за свою часть: входящие события, обработку, память, сценарные решения, ответ клиенту и передачу менеджеру.
понимает текст и формулирует ответы
управляет переходами и бизнес-правилами
хранит состояние, историю и заявки
Telegram Trigger
Получает входящее сообщение клиента из Telegram.
Normalize Message
Приводит Telegram payload к удобной структуре для workflow.
Manager Group Guard
Отсекает сообщения из группы менеджеров, ботов и собственные ответы.
Load / Create State
Загружает или создаёт состояние клиента и активной заявки в PostgreSQL.
Save Incoming Message
Сохраняет сообщение в историю, чтобы диалог можно было отследить.
LLM Extractor
Извлекает intent, услугу, данные авто, контакт, отмену или перенос.
Scenario Engine / FSM
Решает следующий шаг: уточнить данные, продолжить консультацию или готовить handoff.
Update PostgreSQL State
Обновляет profile, active_request, completed_requests и handoff flags.
LLM Reply Writer
Получает готовое решение от workflow и пишет короткий человеческий ответ.
Telegram Reply
Отправляет клиенту ответ: уточнение, консультацию или подтверждение передачи.
Handoff Check
Проверяет, готова ли заявка к передаче менеджеру.
Manager Summary
Формирует чистую заявку: услуга, клиент, телефон, авто, VIN и что сделать.
Manager Handoff
Отправляет подготовленный лид в Telegram-группу менеджеров.
Save Handoff
Фиксирует факт передачи, чтобы не отправлять одну заявку повторно.
Каждый шаг можно отладить отдельно: payload Telegram, состояние в базе, результат extraction, решение сценария, текст ответа и факт handoff. Это сильно упрощает debugging и снижает зависимость от поведения LLM.
n8n управляет
всем процессом
обработки заявки
n8n используется как orchestration layer: принимает Telegram-событие, нормализует payload, загружает состояние из PostgreSQL, вызывает LLM, пропускает результат через сценарную логику и отправляет ответ клиенту или заявку менеджеру.
Telegram Trigger → PostgreSQL → LLM Extractor → Scenario Engine → Reply / Handoff
Telegram Trigger
Workflow стартует с входящего сообщения клиента. Telegram payload приводится к единому формату, чтобы дальше не тянуть хаос по всей цепочке.
PostgreSQL state
Перед обработкой загружается профиль, активная заявка, известные автомобили, история и текущий статус диалога.
LLM Extractor
Модель извлекает intent, услугу, данные авто, имя, телефон, VIN, отмену, перенос и комментарий клиента.
Scenario Engine
Workflow решает следующий шаг: уточнить данные, продолжить консультацию, подтвердить авто, запросить контакт или подготовить handoff.
Reply Writer
Отдельный LLM-слой формулирует ответ клиенту на основе решения workflow, а не принимает бизнес-решение самостоятельно.
Manager summary
Если заявка готова, n8n формирует понятное summary и отправляет его в группу менеджеров без повторных handoff.
Такая сборка позволяет отлаживать каждый слой отдельно: входящий payload, состояние в базе, extraction result, сценарное решение, ответ клиенту и факт передачи заявки менеджеру.
Postgres хранит
память, состояние
и историю заявок
Бот не полагается на память LLM. Профиль клиента, известные автомобили, активная заявка, история сообщений и handoff-статусы хранятся в PostgreSQL и используются workflow как source of truth.
PostgreSQL нужен не “для галочки”, а чтобы бот мог продолжать сценарий, не смешивать старые заявки с новыми и не отдавать модели контроль над состоянием.
клиент, авто, история сообщений
текущий шаг, услуга, handoff flags
active request → completed request
client_profile
имя клиента
контакт для заявки
известные автомобили клиента
последняя активность
active_request
мойка, детейлинг, чип, ремонт
текущий шаг сценария
авто внутри заявки
готовность к передаче
messages
Telegram chat identifier
client / bot / manager
текст сообщения
время события
completed_requests
идентификатор заявки
handoff / completed / cancelled
контекст для менеджера
защита от дублей
Клиент пишет в Telegram
n8n загружает профиль и активную заявку
Scenario Engine обновляет состояние
Postgres сохраняет историю, поля и handoff
После передачи заявки active_request не должен бесконечно висеть в памяти и попадать в новые обращения. Поэтому состояние разделяется на профиль клиента, активную заявку и завершённые запросы.
Диалог работает
как state machine
Каждый ответ клиента меняет состояние сценария. Workflow понимает, что уже собрано, что ещё нужно уточнить, когда продолжить консультацию и когда можно передавать заявку менеджеру.
Без state machine бот начинает повторять вопросы, смешивать старые заявки с новыми и делать handoff слишком рано. Состояния помогают держать сценарий под контролем.
где сейчас находится диалог
каких данных не хватает
что должен сделать workflow
Бот ещё не понял, какая услуга нужна клиенту.
Уточнить направление или определить intent.Клиент задаёт вопрос про услугу, но ещё не оставляет заявку.
Ответить, не делать handoff.Клиент просит совет или сравнивает варианты.
Проконсультировать и дождаться намерения продолжить.Для услуги нужен автомобиль, но данных пока не хватает.
Запросить марку, модель, год или уточнение.В памяти есть автомобиль, но нужно подтвердить, что речь про него.
Спросить: “Речь про ваш BMW X5 или другой автомобиль?”Заявка почти готова, но нет имени или телефона.
Запросить контакт для связи.Собраны нужные данные и есть явное намерение клиента.
Подготовить summary для менеджера.Заявка уже передана менеджеру.
Не отправлять повторный handoff.Клиент хочет отменить или перенести запись.
Передать запрос менеджеру без ложного подтверждения.Заявка завершена или перенесена в историю.
Очистить active_request и не тянуть старые данные дальше.Как одно сообщение клиента двигает сценарий
“Хочу химчистку”
awaiting_service → confirming_known_car
“Речь про ваш BMW X5 или другой автомобиль?”
collecting_contact / handoff_ready
State machine делает поведение бота предсказуемым: LLM помогает понять текст, но переходы, готовность заявки и передача менеджеру зависят от состояния, условий и правил workflow.
Техническая
сборка MVP
Проект собран как Telegram MVP с n8n-оркестрацией, PostgreSQL-памятью, LLM-слоем для извлечения данных и сценарной логикой, которая управляет состояниями, handoff и ответами клиенту.
n8n workflow
Telegram trigger, IF / Switch logic, Code nodes, branching, manager notifications.
Telegram Bot API
Приём сообщений клиента, ответы бота, handoff summary в группу менеджеров.
LLM extraction
Intent, услуга, авто, контакт, отмена, перенос, комментарий клиента.
PostgreSQL
Профиль клиента, автомобили, active request, messages, completed requests.
Scenario Engine
FSM, обязательные поля, handoff rules, защита от дублей и старого контекста.
Execution logs
Проверка payload, состояния, extraction result, SQL-записей и Telegram-ответов.
Спроектировал сценарий первичной обработки заявок для автоцентра.
Собрал n8n workflow: Telegram input, state loading, LLM extraction, scenario logic, reply, handoff.
Подключил PostgreSQL как source of truth для памяти, active_request, истории сообщений и статусов.
Разделил LLM Extractor и Reply Writer, чтобы модель не управляла бизнес-логикой напрямую.
Добавил handoff менеджеру, guard для группы менеджеров, cancel/reschedule flow и защиту от повторной передачи.
Получился не “чат с GPT”, а управляемая workflow-система: Telegram отвечает за канал, n8n — за процесс, LLM — за язык, PostgreSQL — за память, а сценарная логика — за решения.
AI-бот должен быть
не чатом с GPT,
а управляемым
workflow
Проектирую AI-автоматизации, где LLM отвечает за язык, n8n управляет процессом, PostgreSQL хранит состояние, а бизнес-логика остаётся проверяемой и предсказуемой.
AI automation / n8n workflows / Telegram bots / PostgreSQL state
LLM для языка, workflow для решений, база данных для памяти и статусов
MVP, internal tools, lead intake bots, CRM scenarios, QA dashboards
