Веб-приложение для языкового центра: группы, уроки и оплаты

Что именно автоматизировать в языковом центре

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

Обычно проблемы крутятся вокруг трех вещей: уровни (A1, A2, B1, B2), расписание и деньги. Уровни нужны, чтобы не смешивать состав группы и программу. Расписание - чтобы видеть реальную нагрузку преподавателей и не терять переносы. Оплаты и заморозки - потому что именно здесь чаще всего возникают конфликты и «утечки».

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

Что должно быть видно за 10 секунд

На главном экране или в карточке группы должны быть короткие, однозначные ответы:

• состав группы и уровень каждого
• ближайший урок и отмеченные пропуски
• остаток занятий или срок действия абонемента
• активная заморозка (если есть) и дата окончания
• кто просрочил оплату или близок к этому

Что точно не нужно в MVP

На старте мешают не «недостающие функции», а лишняя сложность. Не закладывайте сразу десятки ролей и согласований, глубокую аналитику, витрины KPI, бонусные программы и сложные интеграции. Первое, что должно работать, - точный учет, одинаково понятный администратору и преподавателю.

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

Сущности и связи: группа, урок, ученик, платеж

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

Минимальная модель данных

Группа отвечает за организацию обучения. Обычно достаточно уровня (A1-B2), преподавателя, расписания (дни недели и время), вместимости, дат старта и окончания. Удобно добавить статус: набирается, идет, завершена.

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

Ученик хранит контакты (телефон, мессенджер, почта) и связи с группами. Плюс нужен расчетный показатель: баланс занятий или абонемент (сколько оплачено и сколько осталось). Скидки и редкие исключения на старте не усложняйте - оставьте базовое поле и историю платежей.

Платеж фиксирует деньги: сумма, дата, за какой период или группу, способ оплаты, комментарий администратора и статус (ожидает, оплачен, возврат). Статус выручает, когда деньги «в пути» или был частичный возврат.

Как связать сущности, чтобы не запутаться

Частая схема такая: один ученик может быть в нескольких группах, у каждой группы много уроков. Платеж в MVP лучше привязать одним способом - либо к группе («A2 Пн/Ср»), либо к периоду («за март»). Второй вариант добавите позже.

Пример: Анна учится в разговорной группе B1 и параллельно ходит на грамматику A2. У нее две связи «ученик-группа», посещаемость ведется по урокам каждой группы отдельно. Платежи тоже могут отличаться: за B1 пакет на 8 занятий, за A2 помесячная оплата.

Если вы собираете MVP через чат (например, в TakProsto), эта структура помогает быстро договориться: какие поля нужны, какие связи допустимы и какие экраны должны из этого получиться (группа, журнал уроков, карточка ученика, платежи).

Правила оплаты и заморозки: как формализовать

Чтобы приложение не превращалось в «табличку с примечаниями», сначала договоритесь о простых правилах: как вы принимаете деньги, когда появляется долг и что именно означает заморозка. Чем меньше вариантов на старте, тем меньше ручной работы и спорных ситуаций.

Выберите одну модель оплаты для MVP

Не пытайтесь поддержать все сразу. Выберите один сценарий и доведите его до автоматизма. Например, пакет из 8 уроков на 4 недели.

Наиболее частые модели:

• помесячно (фиксированная сумма за период)
• пакет уроков (N занятий, списание по факту)
• разовый урок (оплата за каждое посещение)

Остальные варианты проще добавить позже, когда станет ясно, что действительно нужно.

Как считать задолженность (один способ)

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

Для пакета самый понятный вариант такой: если баланс уроков стал 0, ученик не записывается на следующий урок, пока не внесет оплату. Если вы допускаете исключение (например, «1 урок в долг»), оформите это отдельным флажком.

Что именно замораживаем

Слово «заморозка» звучит одинаково, но люди часто подразумевают разное. Зафиксируйте один смысл и пропишите его по-человечески. Например:

• заморозка продлевает срок пакета на N дней
• уроки на период заморозки не списываются
• место в группе сохраняется

3-5 правил без двусмысленностей

Набор, который легко автоматизировать и потом объяснять ученикам:

1. Заморозка оформляется минимум за 24 часа до урока.
2. Максимальная заморозка - до 14 дней в рамках одного пакета.
3. Если предупредили позже - урок списывается.
4. Переносы - не более одного переноса на пакет, только при предупреждении заранее.
5. Исключения (болезнь со справкой) подтверждает администратор.

Пример: Анна купила пакет на 8 уроков. После 3 занятий попросила заморозку на неделю и предупредила за два дня. Срок пакета продлился на 7 дней, уроки не списывались. Если бы она написала в день занятия, урок считался бы проведенным.

Когда правила записаны, их легко «перевести» в поля и переключатели и собрать MVP без бесконечных уточнений.

Что включить в MVP, чтобы он реально заработал

MVP для языкового центра должен закрывать ежедневные действия администратора: кто в какой группе, какие уроки прошли, кто оплатил, у кого сейчас заморозка. Если это работает без обходных таблиц, веб-приложение уже приносит пользу даже без сложных отчетов.

Хорошее правило: оставьте только то, что нужно, чтобы вести одну реальную группу от начала до конца месяца и не спорить по деньгам.

Минимальный набор экранов и действий

В MVP обычно достаточно пяти экранов:

• список групп и карточка группы (уровень, расписание, преподаватель, активные ученики)
• журнал уроков (посещение, перенос/отмена, короткий комментарий)
• учет оплат (кто оплатил, кто должен, история платежей)
• заморозки (создать/продлить/закрыть и сразу видеть влияние на учет)
• карточка ученика (контакты, группы, баланс/долг, активные заморозки)

Сразу договоритесь о понятных статусах. Чем меньше вариантов, тем меньше ошибок: урок «проведен/перенесен/отменен», платеж «ожидает/оплачен/возврат», заморозка «активна/закрыта».

Импорт на старте: как занести текущих учеников без боли

Запуск часто тормозит не разработка, а перенос данных. Для MVP достаточно простого сценария: сначала руками ввести 10-20 учеников, чтобы проверить логику на живых данных, а потом импортировать из таблицы с минимумом колонок (ФИО, телефон, группа, дата начала, оплачено до). Дубли проще ловить по телефону (или по паре «ФИО + телефон») и после импорта быстро сверить: открываете группу и проверяете, что долги и заморозки совпали с реальностью.

Пошагово: собрать MVP через чат, без лишней теории

MVP проще собрать, когда вы описываете реальную работу центра, а не «идеальную систему». Сначала закройте ежедневные действия администратора и преподавателя, и только потом добавляйте красоту, отчеты и рассылки.

Шаги, которые дают результат за 1-2 итерации

Двигайтесь небольшими порциями:

1. Опишите цели и роли простыми фразами: «админ создает группы и отмечает оплаты», «преподаватель отмечает посещение», «ученик видит расписание и статус».
2. Перечислите сущности и поля: группа, урок, ученик, платеж, заморозка.
3. Набросайте 4-6 экранов и быстрые действия: «отметить оплату/посещение/заморозку».
4. Попросите собрать черновой интерфейс и базовую логику: создание группы, добавление учеников, генерация уроков по расписанию, учет платежей, расчет баланса.
5. Загрузите тестовые данные и прогоните жизненные сценарии: «10 уроков в месяце, 3 ученика, один заморозил 2 занятия, один оплатил частично».

Чтобы вас правильно поняли, помогает один «эталонный запрос»:

Сделай MVP для языкового центра.
Роли: админ, преподаватель.
Сущности: Группа(уровень, расписание), Урок(дата, посещения), Ученик(контакты), Платеж(сумма, дата), Заморозка(с даты по дату).
Правила: заморозка не списывает занятия, баланс ученика сохраняется, долг считается как (начислено - оплачено).
Нужны экраны: группы, карточка группы, уроки, ученики, платежи.

Зафиксируйте «что такое правильно» до доработок

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

Мини-проверка: ученик оплатил 8 занятий, посетил 6, заморозил неделю (2 урока). Итог должен быть простой: списано 6, осталось 2, заморозка не превратилась в «пропуск», долг не появился. Если это одинаково видно в журнале, карточке ученика и в группе, MVP готов к работе.

Сценарии по ролям: админ, преподаватель, ученик

Разложите работу по ролям сразу. Тогда каждому показывается только то, что нужно на день, и меньше ошибок в оплатах и посещаемости.

Администратор: «собрать группу и держать порядок в деньгах»

День админа - это действия: создать группу по уровню, набрать людей и вовремя видеть, кто оплатил. В простом сценарии админ заводит группу (уровень, расписание, преподаватель), добавляет учеников и фиксирует оплату.

Заморозка тоже должна быть у админа, потому что она почти всегда влияет на деньги. Удобно, когда заморозка оформляется как отдельное событие с датами и причиной, а система сама пересчитывает доступные занятия или переносит списания по вашему правилу.

Преподаватель: «провести урок и оставить след»

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

Ученик: «минимум, чтобы не дергать администратора»

В MVP ученику достаточно видеть расписание своей группы и статус: «оплачено до N занятий» или «нужна оплата». Полноценный личный кабинет с документами и деталями платежей можно отложить.

Права доступа лучше разделить жестко:

• только админ редактирует платежи и оформляет заморозку
• преподаватель отмечает посещаемость и пишет комментарии, но не меняет суммы и даты оплат
• перенос расписания и удаление уроков - только админ
• ученик видит только свои данные и свою группу

Пример из практики: один месяц работы группы по уровню

Открываем группу B1 на 8 недель: 10 учеников, занятия по вторникам и четвергам. Администратор заносит группу один раз, а дальше каждое занятие появляется как отдельный урок со статусом (проведен, отменен, перенесен) и списком учеников.

Оплата помесячная. В карточке ученика видно: тариф за месяц, сколько оплачено, сколько осталось и крайний срок. Например, из 10 человек 7 оплатили полностью в первые 3 дня, 2 внесли половину, 1 задержал оплату. Важно, что частичный платеж не выглядит как «все ок»: пока сумма не закрыта, статус остается «долг».

На второй неделе два ученика уезжают в отпуск на 10 дней. Администратор оформляет заморозку с датами. Правило простое: заморозка не стирает историю, она только продлевает период доступа или срок абонемента. В расписании эти ученики отмечаются как «на заморозке», чтобы преподаватель не ждал их и не считал это пропуском.

На третьей неделе один урок отменили (преподаватель заболел). У отмененного урока ставится причина и флаг «не учитывать как проведенный». Дальше вы выбираете правило по деньгам. Если оплата фиксированная за месяц - переносите урок на резервную дату. Если оплата по количеству занятий - урок не списывается.

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

Частые ошибки в учете оплат, уроков и заморозок

Самые неприятные проблемы в языковом центре чаще начинаются не с «плохой CRM», а с неясных правил. Сначала решите, какие события считаются фактом (проведенный урок, перенос, отмена, платеж, заморозка), а уже потом автоматизируйте.

1) Смешали разные модели оплаты в одной группе

Часть учеников платит «за месяц», часть - «за 8 занятий», третья - «по факту». Администратор пытается вести это вместе и быстро теряет картину: у кого долг, у кого переплата, что переносится.

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

2) Не прописали, что делать при отмене урока

Если урок отменил преподаватель, ученик ожидает перенос или возврат. Если отменил ученик, центр ожидает списание. Когда правил нет, каждый спор превращается в ручные переговоры.

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

3) Заморозка без ограничений

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

4) Редактирование платежей без истории

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

5) Нет единого источника правды

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

Быстрый чеклист перед запуском для администратора

Перед запуском проверьте систему на реальных данных (1-2 группы и 5-10 учеников). Это дешевле, чем потом разбирать, почему «цифры не сходятся».

Минимальный набор проверок:

• статусы групп однозначны (набор/идет/закрыта)
• по каждому ученику видно финансовое состояние (ноль/долг/переплата) и оно одинаковое в карточке, группе и отчете
• у каждого платежа есть дата, сумма, период (например, «за март» или «за 4 занятия») и комментарий
• заморозка - отдельное событие со сроком (с/по) и причиной, она не ломает расчеты по вашему правилу
• за пару минут находите тех, кому нужно оплатить на этой неделе (без ручной сверки таблиц)

Проверьте сценарий: ученик оплатил 8 занятий, посетил 3, потом заморозил на 2 недели, вернулся и оплатил еще 4. После этих действий баланс должен выглядеть логично без ручных правок.

Отдельное правило перед любыми правками в правилах или формах: сохраняйте версию. В TakProsto это удобно делать через снимки (snapshots) и откат (rollback) - можно править спокойно и быстро вернуться к рабочему состоянию, если что-то «поехало» в расчетах.

Дальнейшие шаги: напоминания, отчеты и спокойное развитие MVP

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

Напоминания: отдельный этап, отдельные правила

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

Обычно достаточно:

• напоминание об оплате за 3 дня до дедлайна
• уведомление о просрочке на следующий день
• напоминание о занятии за 2-3 часа до старта (только тем, кто не на заморозке)
• сигнал о конце абонемента, когда осталось 1-2 занятия
• администратору - список «под вопросом» (нет оплаты и нет активной заморозки)

Важно, чтобы напоминания опирались на факты в системе (статусы платежей, лимиты заморозки, расписание), а не на ручные пометки.

Отчеты: простые, но регулярные

Не гонитесь за красивыми дашбордами. На старте обычно хватает трех отчетов: должники, посещаемость, загрузка групп. Хороший отчет показывает не только сумму, но и причину: «платеж не внесен», «заморозка активна до пятницы», «занятия закончились, нужен новый пакет».

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

Как расширяться без переделки

Если сущности и правила четкие, новые функции добавляются слоями: скидки, семейные аккаунты, онлайн-уроки, разные типы абонементов.

Если вам важно быстро собрать рабочий прототип без классической разработки, TakProsto (takprosto.ai) как раз заточен под создание веб, серверных и мобильных приложений через чат, с режимом планирования и возможностью отката по снимкам. Когда система «встанет на рельсы», пригодятся экспорт исходников и развертывание с хостингом - особенно если принципиально, чтобы все работало на серверах в России.