PayTutor: CRM для учебного центра — от заявки в Telegram до сертификата

Проблема

Учебные центры, репетиторы и авторы закрытых Telegram-курсов ведут запись, оплату и посещаемость вручную — в Excel, блокнотах и переписке. Клиент пишет вопрос, администратор вручную считает стоимость, отправляет реквизиты, ждёт скриншот перевода, потом вручную зачисляет ученика в группу и отмечает посещаемость на бумаге или в отдельной таблице.

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

У владельца учебного центра при этом нет единой картины: сколько учеников в каждой группе и филиале, кто оплатил, а у кого задолженность, какая посещаемость и успеваемость. Вся история держится на памяти администратора и переписке, которую невозможно быстро просмотреть при разборе спорной ситуации.

Не просто бот: CRM для всего учебного центра

PayTutor — не отдельный Telegram-бот приёма оплаты, а полноценная CRM для учебного центра, репетитора или курсов. Telegram-бот — это только канал, через который ученик подаёт заявку, записывается на пробный урок и оплачивает обучение. Вся операционка центра — на стороне админ-панели.

В админ-панели: заказы и оплаты, заявки и пробные уроки, расписание и занятия, экзамены и табель успеваемости, ученики (с историей переписки и клик-to-call прямо из карточки), группы, преподаватели, предметы, филиалы и автоматическая выдача сертификатов об окончании. Живая демо-версия работает на реальных демо-данных — 3 филиала, 9 преподавателей, 14 активных групп и 51 ученик — и показывает не макет, а действующую систему.

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

Идея решения и подход к прозрачной демо-версии

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

Отдельно решался вопрос честности демонстрации: технические webhook- и платёжные endpoint'ы не индексируются и не публикуются как открытый продукт — наружу выведен только этот кейс и безопасный mock-режим оплаты. Это осознанный компромисс между «показать, как работает» и «не раскрывать рабочую инфраструктуру и секреты клиента».

Сценарий в Telegram-боте

Ядро продукта — бот, который ведёт клиента по сценарию через инлайн-меню, а не через свободный текст. После команды /start клиент видит главное меню: «Купить уроки», «Доступ в закрытый канал», «Юридическая информация», «Поддержка». Каждый пункт — отдельная предсказуемая ветка диалога.

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

Выбор формата и расчёт стоимости

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

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

Приём оплаты: два варианта симуляции платёжного шлюза

Для демонстрации приёма оплаты собраны два варианта mock-страницы: лаконичная страница «Страница оплаты» с суммой и кнопками «Оплатить» / «Отмена», и более подробный «Симулятор FreedomPay», стилизованный под реальный локальный платёжный шлюз, с явной пометкой «ТЕСТОВЫЙ РЕЖИМ · NOINDEX» и кнопками имитации успеха и ошибки оплаты.

Оба варианта показывают одну и ту же архитектурную идею: страница оплаты — заменяемый модуль. В продакшене на этом месте стоит реальный платёжный шлюз (например, Payme, Click или FreedomPay), а логика бота — приём callback, обновление статуса заказа, выдача доступа — остаётся неизменной. Это разделение ответственности упрощает подключение нового платёжного провайдера без переписывания сценария бота.

Подтверждение и мгновенная выдача продукта

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

Ключевой принцип — никакого ожидания живого человека на этом шаге. Номер заказа, инструкция и доступ формируются автоматически сразу после подтверждения оплаты, а не после того, как кто-то из команды заметит уведомление и вручную ответит клиенту.

Уведомления для владельца в реальном времени

Параллельно с подтверждением для клиента бот отправляет отдельное уведомление владельцу — «Новая продажа!» с номером заказа, типом покупки, суммой и ID клиента. Это отдельный канал информации: владельцу не нужно держать открытой админ-панель или регулярно проверять таблицу заказов, чтобы понимать, что происходит с продажами прямо сейчас.

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

Честная демонстрация: что здесь по-настоящему, а что — mock

Отдельная забота при подготовке публичного кейса — не вводить посетителя в заблуждение насчёт того, что именно он видит. Поэтому на странице кейса прямо расписана 4-шаговая схема работы demo-стенда: клиент проходит сценарий в боте, вместо реальной кассы открывается mock-страница, вместо настоящего webhook — имитация callback с результатом «успех» или «отмена», и только в production-версии реальный webhook обновляет базу данных и бот выдаёт продукт по-настоящему.

Рядом расположен блок живого демо: кнопки «Открыть @PayTutorDemoBot» и «Полная инструкция», список команд — /start для запуска сценария, /demo для инструкции, /reset чтобы начать заново, — и честная оговорка, что демо работает, пока включён ноутбук с локальным сервером и туннелем, то есть не на постоянной продакшен-инфраструктуре.

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

Результат

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

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