Telegram-бот для приёма заявок: архитектура, которая не разваливается

Бизнес теряет клиентов в первом контакте: сообщение пришло ночью, менеджер не ответил за минуту, человек ушёл к конкуренту. Бот закрывает это 24/7 — но большинство ботов это хрупкие скрипты, которые ломаются на первом нестандартном вводе. Разберём архитектуру, на которой бот растёт от «меню» до полноценного приёма заявок с интеграциями.

Три работы бизнес-бота

Полезный бот делает три вещи, и их стоит проектировать раздельно:

• Навигация (меню). Клиент не теряется: услуги, цены, заявка, вопрос — в одно нажатие, а не «напишите менеджеру и ждите».
• Приём заявки. Пошагово собирает имя, контакт, задачу, показывает сводку на подтверждение и тут же уведомляет менеджера.
• Ответы на вопросы. Типовое (сроки, оплата, гарантии) — мгновенно; чего не знает — честно говорит и предлагает оставить заявку.

Главный принцип: логика отдельно от Telegram

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

def handle(session, text) -> Reply:
    # чистая логика: вход — сообщение и состояние,
    # выход — текст ответа + кнопки. Ни Telegram, ни сети.

Что это даёт: ядро гоняется в офлайн-симуляторе без токена (быстрые тесты и демо), Telegram подключается тонким адаптером (aiogram), а при необходимости тот же сценарий переносится в WhatsApp или виджет на сайт. Это и отличает «бота под ключ» от одноразового скрипта.

Приём заявки — это конечный автомат (FSM)

Сбор заявки — последовательность шагов с состоянием: имя → контакт → задача → подтверждение → готово. Городить это на вложенных if — путь к хаосу: бот забывает, на каком шаге клиент, ломается на «назад» и «отмена». Конечный автомат (FSM) держит состояние явно: на каждом шаге понятно, что бот ждёт и куда перейдёт.

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

Уведомление менеджеру — момент конверсии

Как только заявка подтверждена, бот сразу шлёт её в чат менеджера (или в группу): имя, контакт, задача. Это и есть точка, ради которой всё затевалось — вы получаете готовый лид с контактами, а не «пропущенное сообщение» в три часа ночи. Дальше заявка уходит в CRM.

→ Нужен такой бот приёма заявок? Пройдите живого бота на странице кейса →

Ответы на вопросы: от FAQ до базы знаний

Простой FAQ (по ключевым словам) закрывает типовое. Когда вопросов много и они про ваши документы — FAQ заменяется на полноценный поиск по базе знаний (RAG): бот находит ответ во всей вашей базе и даёт его со ссылкой на источник, а не по жёстко прописанным темам. Как сделать так, чтобы при этом бот не выдумывал — отдельная тема, разобрали в статье «ИИ-чатбот, который не врёт».

Интеграции и надёжность

• CRM — заявки сразу в amoCRM, Bitrix24 или Google Sheets, без ручного переноса.
• Оплаты — приём платежей или бронирование прямо в боте.
• Рассылки и напоминания — по событию или расписанию, сегментам.
• Эксплуатация 24/7 — деплой на вашем сервере, мониторинг, автоперезапуск. Чините не вы.

Частые грабли

• Нет сохранения состояния. Перезапуск — и бот забыл всех на полушаге. Состояние должно жить в БД/Redis, не только в памяти.
• Блокирующие обработчики. Долгая операция в одном диалоге подвешивает бота для всех. Нужен асинхронный код.
• Нет «отмены». Клиент застрял в форме без выхода — закрывает бота. Всегда давайте «отмена»/«меню».
• Нет аналитики воронки. Не видно, на каком шаге отваливаются клиенты — нечего чинить. Логируйте переходы.

Проверьте на живом боте

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