Веб-приложение для языкового центра: как описать группы, уроки, учеников и платежи, настроить заморозки и быстро собрать MVP, а рассылку добавить позже.
Если в центре больше пары групп, ручной учет быстро превращается в хаос: кто в какой группе, за что уже оплатили, кто переносил уроки, у кого заморозка и до какого числа. В итоге администратор тратит время на переписки и таблицы вместо записи новых учеников.
Обычно проблемы крутятся вокруг трех вещей: уровни (A1, A2, B1, B2), расписание и деньги. Уровни нужны, чтобы не смешивать состав группы и программу. Расписание - чтобы видеть реальную нагрузку преподавателей и не терять переносы. Оплаты и заморозки - потому что именно здесь чаще всего возникают конфликты и «утечки».
Приложение одновременно нужно разным людям. Администратору важны контроль и порядок, преподавателю - список учеников на урок и понятный статус по занятиям, ученику - минимум информации, чтобы не спрашивать каждый раз: когда следующее занятие и сколько осталось.
На главном экране или в карточке группы должны быть короткие, однозначные ответы:
На старте мешают не «недостающие функции», а лишняя сложность. Не закладывайте сразу десятки ролей и согласований, глубокую аналитику, витрины KPI, бонусные программы и сложные интеграции. Первое, что должно работать, - точный учет, одинаково понятный администратору и преподавателю.
Практичный путь - собрать минимальную версию через чат: описать процессы словами, согласовать термины и сделать экраны для ежедневных действий. Напоминания и отчеты добавите позже, когда базовый учет перестанет «сыпаться».
Чтобы веб-приложение для языкового центра не превратилось в набор разрозненных таблиц, начните с четырех сущностей: группа, урок, ученик, платеж. Дальше важнее не усложнять, а фиксировать то, что администратор реально делает каждый день.
Группа отвечает за организацию обучения. Обычно достаточно уровня (A1-B2), преподавателя, расписания (дни недели и время), вместимости, дат старта и окончания. Удобно добавить статус: набирается, идет, завершена.
Урок всегда принадлежит конкретной группе. У него есть дата и время, короткая тема (по желанию), статус (прошел/отменен/перенесен) и посещаемость. Посещаемость лучше хранить не текстом, а простым значением для каждого ученика: был, не был, уважительная причина, на заморозке.
Ученик хранит контакты (телефон, мессенджер, почта) и связи с группами. Плюс нужен расчетный показатель: баланс занятий или абонемент (сколько оплачено и сколько осталось). Скидки и редкие исключения на старте не усложняйте - оставьте базовое поле и историю платежей.
Платеж фиксирует деньги: сумма, дата, за какой период или группу, способ оплаты, комментарий администратора и статус (ожидает, оплачен, возврат). Статус выручает, когда деньги «в пути» или был частичный возврат.
Частая схема такая: один ученик может быть в нескольких группах, у каждой группы много уроков. Платеж в MVP лучше привязать одним способом - либо к группе («A2 Пн/Ср»), либо к периоду («за март»). Второй вариант добавите позже.
Пример: Анна учится в разговорной группе B1 и параллельно ходит на грамматику A2. У нее две связи «ученик-группа», посещаемость ведется по урокам каждой группы отдельно. Платежи тоже могут отличаться: за B1 пакет на 8 занятий, за A2 помесячная оплата.
Если вы собираете MVP через чат (например, в TakProsto), эта структура помогает быстро договориться: какие поля нужны, какие связи допустимы и какие экраны должны из этого получиться (группа, журнал уроков, карточка ученика, платежи).
Чтобы приложение не превращалось в «табличку с примечаниями», сначала договоритесь о простых правилах: как вы принимаете деньги, когда появляется долг и что именно означает заморозка. Чем меньше вариантов на старте, тем меньше ручной работы и спорных ситуаций.
Не пытайтесь поддержать все сразу. Выберите один сценарий и доведите его до автоматизма. Например, пакет из 8 уроков на 4 недели.
Наиболее частые модели:
Остальные варианты проще добавить позже, когда станет ясно, что действительно нужно.
Долг должен считаться одинаково для всех групп, иначе администратор будет каждый раз объяснять правила заново. Обычно выбирают один подход: по дате (оплатить до X числа), по количеству уроков (баланс занятий должен быть положительным) или по периоду (оплачен месяц - можно ходить).
Для пакета самый понятный вариант такой: если баланс уроков стал 0, ученик не записывается на следующий урок, пока не внесет оплату. Если вы допускаете исключение (например, «1 урок в долг»), оформите это отдельным флажком.
Слово «заморозка» звучит одинаково, но люди часто подразумевают разное. Зафиксируйте один смысл и пропишите его по-человечески. Например:
Набор, который легко автоматизировать и потом объяснять ученикам:
Пример: Анна купила пакет на 8 уроков. После 3 занятий попросила заморозку на неделю и предупредила за два дня. Срок пакета продлился на 7 дней, уроки не списывались. Если бы она написала в день занятия, урок считался бы проведенным.
Когда правила записаны, их легко «перевести» в поля и переключатели и собрать MVP без бесконечных уточнений.
MVP для языкового центра должен закрывать ежедневные действия администратора: кто в какой группе, какие уроки прошли, кто оплатил, у кого сейчас заморозка. Если это работает без обходных таблиц, веб-приложение уже приносит пользу даже без сложных отчетов.
Хорошее правило: оставьте только то, что нужно, чтобы вести одну реальную группу от начала до конца месяца и не спорить по деньгам.
В MVP обычно достаточно пяти экранов:
Сразу договоритесь о понятных статусах. Чем меньше вариантов, тем меньше ошибок: урок «проведен/перенесен/отменен», платеж «ожидает/оплачен/возврат», заморозка «активна/закрыта».
Запуск часто тормозит не разработка, а перенос данных. Для MVP достаточно простого сценария: сначала руками ввести 10-20 учеников, чтобы проверить логику на живых данных, а потом импортировать из таблицы с минимумом колонок (ФИО, телефон, группа, дата начала, оплачено до). Дубли проще ловить по телефону (или по паре «ФИО + телефон») и после импорта быстро сверить: открываете группу и проверяете, что долги и заморозки совпали с реальностью.
MVP проще собрать, когда вы описываете реальную работу центра, а не «идеальную систему». Сначала закройте ежедневные действия администратора и преподавателя, и только потом добавляйте красоту, отчеты и рассылки.
Двигайтесь небольшими порциями:
Чтобы вас правильно поняли, помогает один «эталонный запрос»:
Сделай MVP для языкового центра.
Роли: админ, преподаватель.
Сущности: Группа(уровень, расписание), Урок(дата, посещения), Ученик(контакты), Платеж(сумма, дата), Заморозка(с даты по дату).
Правила: заморозка не списывает занятия, баланс ученика сохраняется, долг считается как (начислено - оплачено).
Нужны экраны: группы, карточка группы, уроки, ученики, платежи.
Отдельно согласуйте критерии правильного результата: как считается долг, что показывает баланс, какой статус у ученика (активен, на заморозке, выбыл), и что происходит, если платеж пришел после пары занятий.
Мини-проверка: ученик оплатил 8 занятий, посетил 6, заморозил неделю (2 урока). Итог должен быть простой: списано 6, осталось 2, заморозка не превратилась в «пропуск», долг не появился. Если это одинаково видно в журнале, карточке ученика и в группе, MVP готов к работе.
Разложите работу по ролям сразу. Тогда каждому показывается только то, что нужно на день, и меньше ошибок в оплатах и посещаемости.
День админа - это действия: создать группу по уровню, набрать людей и вовремя видеть, кто оплатил. В простом сценарии админ заводит группу (уровень, расписание, преподаватель), добавляет учеников и фиксирует оплату.
Заморозка тоже должна быть у админа, потому что она почти всегда влияет на деньги. Удобно, когда заморозка оформляется как отдельное событие с датами и причиной, а система сама пересчитывает доступные занятия или переносит списания по вашему правилу.
Преподавателю не нужны платежи и редактирование расписания. Ему нужен экран «сегодня»: какие уроки, кто в группе и что отметить после занятия. После урока он ставит посещаемость и, если важно, короткий комментарий (например, «перешли к Past Simple, дать домашку»). Это помогает админу разруливать спорные ситуации без звонков.
В MVP ученику достаточно видеть расписание своей группы и статус: «оплачено до N занятий» или «нужна оплата». Полноценный личный кабинет с документами и деталями платежей можно отложить.
Права доступа лучше разделить жестко:
Открываем группу B1 на 8 недель: 10 учеников, занятия по вторникам и четвергам. Администратор заносит группу один раз, а дальше каждое занятие появляется как отдельный урок со статусом (проведен, отменен, перенесен) и списком учеников.
Оплата помесячная. В карточке ученика видно: тариф за месяц, сколько оплачено, сколько осталось и крайний срок. Например, из 10 человек 7 оплатили полностью в первые 3 дня, 2 внесли половину, 1 задержал оплату. Важно, что частичный платеж не выглядит как «все ок»: пока сумма не закрыта, статус остается «долг».
На второй неделе два ученика уезжают в отпуск на 10 дней. Администратор оформляет заморозку с датами. Правило простое: заморозка не стирает историю, она только продлевает период доступа или срок абонемента. В расписании эти ученики отмечаются как «на заморозке», чтобы преподаватель не ждал их и не считал это пропуском.
На третьей неделе один урок отменили (преподаватель заболел). У отмененного урока ставится причина и флаг «не учитывать как проведенный». Дальше вы выбираете правило по деньгам. Если оплата фиксированная за месяц - переносите урок на резервную дату. Если оплата по количеству занятий - урок не списывается.
В конце месяца администратору нужен быстрый срез без ручных сверок. Обычно хватает простого отчета: кто в долге и на какую сумму, кто на заморозке и до какой даты, сколько уроков проведено/отменено/перенесено, сколько свободных мест в группе, кто не ходит две недели подряд.
Самые неприятные проблемы в языковом центре чаще начинаются не с «плохой CRM», а с неясных правил. Сначала решите, какие события считаются фактом (проведенный урок, перенос, отмена, платеж, заморозка), а уже потом автоматизируйте.
Часть учеников платит «за месяц», часть - «за 8 занятий», третья - «по факту». Администратор пытается вести это вместе и быстро теряет картину: у кого долг, у кого переплата, что переносится.
Лучше выбрать одну модель на группу и зафиксировать ее. Если исключения неизбежны, оформляйте их явно как отдельный тариф или тип абонемента, а не «договорились в чате».
Если урок отменил преподаватель, ученик ожидает перенос или возврат. Если отменил ученик, центр ожидает списание. Когда правил нет, каждый спор превращается в ручные переговоры.
Закрепите хотя бы базу: кто может отменять урок и за сколько часов, что считается переносом, списывается ли занятие при поздней отмене, как действует замена преподавателя, как закрывается период (месяц или пакет).
Если заморозку можно включать бесконечно и задним числом, период невозможно закрыть: абонементы тянутся, долги «висят», отчеты не сходятся. Нужны ограничения: максимум дней заморозки, минимальный срок уведомления, запрет редактирования после закрытия месяца.
Удалили платеж, исправили сумму, поменяли дату - через неделю никто не помнит, что произошло. Нужен журнал изменений: кто, когда, что поменял и почему (хотя бы короткая причина).
Часть данных в мессенджере, часть в таблице, часть в блокноте преподавателя. Потом вы тратите часы на сверку. Выберите одно место, где живут факты: уроки, посещаемость, платежи и заморозки.
Перед запуском проверьте систему на реальных данных (1-2 группы и 5-10 учеников). Это дешевле, чем потом разбирать, почему «цифры не сходятся».
Минимальный набор проверок:
Проверьте сценарий: ученик оплатил 8 занятий, посетил 3, потом заморозил на 2 недели, вернулся и оплатил еще 4. После этих действий баланс должен выглядеть логично без ручных правок.
Отдельное правило перед любыми правками в правилах или формах: сохраняйте версию. В TakProsto это удобно делать через снимки (snapshots) и откат (rollback) - можно править спокойно и быстро вернуться к рабочему состоянию, если что-то «поехало» в расчетах.
Когда MVP уже держит базу (группы, уроки, платежи, заморозки), добавляйте только то, что снижает ручную работу и ошибки. Обычно это два направления: напоминания и отчеты.
Напоминания лучше делать вторым шагом, чтобы не сломать логику учета. Начните с одного канала, а мессенджеры подключайте позже, когда тексты и тайминги уже проверены.
Обычно достаточно:
Важно, чтобы напоминания опирались на факты в системе (статусы платежей, лимиты заморозки, расписание), а не на ручные пометки.
Не гонитесь за красивыми дашбордами. На старте обычно хватает трех отчетов: должники, посещаемость, загрузка групп. Хороший отчет показывает не только сумму, но и причину: «платеж не внесен», «заморозка активна до пятницы», «занятия закончились, нужен новый пакет».
Чтобы данные были чистыми, закрепите процесс: преподаватель вносит посещаемость в день занятия, администратор подтверждает платежи раз в день в одно и то же время, заморозку заводит только администратор, любые изменения задним числом требуют комментария.
Если сущности и правила четкие, новые функции добавляются слоями: скидки, семейные аккаунты, онлайн-уроки, разные типы абонементов.
Если вам важно быстро собрать рабочий прототип без классической разработки, TakProsto (takprosto.ai) как раз заточен под создание веб, серверных и мобильных приложений через чат, с режимом планирования и возможностью отката по снимкам. Когда система «встанет на рельсы», пригодятся экспорт исходников и развертывание с хостингом - особенно если принципиально, чтобы все работало на серверах в России.
Начните с того, что чаще всего вызывает путаницу: состав групп и уровни, расписание и переносы, а также оплаты, долги и заморозки. Если эти три блока ведутся одинаково для всех, администратор перестает «сверять по чатам», а преподаватель видит понятный журнал занятий.
Сфокусируйтесь на ежедневных задачах: создать группу, добавить учеников, автоматически получить список уроков по расписанию, отметить посещаемость, зафиксировать платеж и оформить заморозку. Все остальное, включая красивые отчеты и рассылки, лучше добавлять после того, как базовый учет перестал требовать ручных обходных путей.
Держите модель минимальной: группа, урок, ученик, платеж и отдельно заморозка. Добавляйте только те поля, которые администратор использует каждый день, иначе появятся «пустые обязательные поля» и ошибки при вводе.
Закрепите один вариант связи на старте: платеж либо относится к группе, либо относится к периоду. Для MVP обычно проще привязка к группе, потому что так легче понять, за что человек платит, и проще считать долги внутри конкретного расписания.
Выберите один принцип и применяйте везде, например: долг есть, если баланс занятий стал нулевым и оплаты нет. Если вы разрешаете исключение вроде «одно занятие в долг», сделайте это явным флажком, а не договоренностью в переписке, чтобы правило было одинаковым для всех.
Зафиксируйте один смысл заморозки и не смешивайте варианты. Практичный стандарт: на период заморозки занятия не списываются, срок пакета продлевается, место в группе сохраняется, а в журнале посещаемости ученик отмечается как «на заморозке», а не как пропуск.
Сначала договоритесь о простых правилах и ограничениях, например: оформление не позже чем за 24 часа, максимум дней в рамках пакета, запрет задним числом без комментария. Чем меньше исключений, тем меньше ручных правок и тем проще администратору объяснять логику ученикам.
Сделайте ему экран «сегодня» или «урок»: список учеников, отметки посещаемости и короткий комментарий по занятию. Не давайте преподавателю доступ к суммам, датам платежей и редактированию расписания, чтобы финансовые данные не менялись случайно.
Начните с ручного ввода 10–20 учеников, чтобы проверить логику на живых сценариях, а затем импортируйте таблицу с минимумом колонок, например ФИО, телефон, группа, дата начала, оплачено до. Дубли удобнее ловить по телефону, а после импорта быстро сверять по карточке группы: долги и заморозки должны совпадать с реальностью.
Опишите процессы простыми фразами, перечислите сущности и поля, затем попросите собрать черновые экраны и прогнать тестовые сценарии с оплатой, частичным платежом, переносом и заморозкой. В TakProsto удобно идти итерациями и фиксировать рабочие версии снимками, чтобы спокойно менять правила и быстро откатываться, если расчеты «поехали».