У EdTech-маркетплейса есть две группы пользователей. Первые оплачивают курсы — для них делают каталог, поиск, карточки, бронирование и оплату. Вторые на платформе зарабатывают — для них обычно создают профиль, список заказов и чат.
Покупатель заходит несколько раз в неделю, исполнитель работает каждый день. Но инструментов для ежедневной работы у него почти нет — и она постепенно расползается по внешним сервисам: расписание в Google Calendar, коммуникация в мессенджер, финансы в Excel. Платформа остается только точкой первого контакта.
В этой статье разбираем, как мы проектировали ЛК самозанятого учителя для Course.Tours — и почему он превратился в 12-модульный SaaS внутри EdTech-маркетплейса. Полный кейс с деталями проекта — на сайте MWI.
Преподаватель провел десять занятий. Пришла выплата, которая не сходится с его подсчетами. Он пишет в поддержку, получает ответ через день — и в следующем месяце история повторяется, потому что внутри платформы нет разбивки по заказам, нет истории транзакций, нет документов, только строка «баланс». После нескольких таких итераций он не уходит демонстративно — просто перестает вкладываться: не обновляет курсы, часть студентов ведет напрямую. Платформа теряет комиссию не когда преподаватель уходит, а задолго до этого. Именно такого сценария хотелось избежать в случае с Course.Tours.
Course.Tours — международный EdTech-маркетплейс с моделью «обучение + путешествие»: 30 000+ курсов, языковые лагеря, онлайн- и офлайн-занятия с бронированием проживания и визовой поддержкой. Команда MWI проектировала личный кабинет самозанятого преподавателя как полноценный SaaS-инструмент внутри платформы: с курсами, расписанием, заявками, чатами, материалами, отчетами и выплатами.
Чтобы преподаватель работал внутри платформы, а не в обход нее, ему нужны расписание, мессенджер, заявки, библиотека материалов и прозрачный финансовый учет. Поэтому личный кабинет вырос до 12 модулей.
Ценность кабинета формируют не набор модулей как таковой, а конкретные продуктовые решения внутри них. Ниже — те из них, где выбор был наименее очевидным.
Дашборд, профиль, группы, материалы, поиск — модули с понятной логикой. Но в курсах было принято решение, которое на первый взгляд выглядит ограничением.
Преподаватель не может опубликовать курс напрямую. Только черновик → модерация → опубликован → архив. Платформа сохраняет контроль над качеством каталога, история изменений остается доступной для аудита.
Если пересечение занятий обнаруживается уже во время урока, исправлять ситуацию поздно. Поэтому система проверяет расписание заранее и предупреждает о конфликтах еще на этапе планирования.
Если занятия пересекаются на 10 минут и более, система подсвечивает конфликт в расписании, чтобы преподаватель мог быстро его исправить.
Воронка заявок: входящая заявка → согласование → выставление счета → подтверждение → выполнение. Чат 1:1 со студентом открывается только после подтверждения оплаты.
Это помогает сохранить ценность внутри маркетплейса: преподаватели работают с подтвержденными заявками, а сделка не уходит в сторонние каналы до оплаты.
Чаты спроектированы под образовательный процесс: личные диалоги 1:1, группы по курсам, административные чаты и проектные подгруппы. Для каждой роли прописаны права доступа. Сообщение можно привязать к курсу, уроку или домашнему заданию, чтобы участники сразу понимали контекст. Редактирование доступно 15 минут, а преподаватель может модерировать чат и удалять сообщения для всех.
Материалы — учебная библиотека с тегами, версиями и поиском. Файлы можно связать с курсом, занятием или заданием, а права доступа разделить: что видит ученик, что остается у преподавателя.
Финансы и выплаты — раздел ЛК, где преподаватель видит свой доход по занятиям: оплаченные заказы, суммы, комиссии платформы, статус и дату ближайшей выплаты. Документы и операции можно выгрузить в CSV или PDF.
Отчеты, поддержка и поиск собирают рабочий контекст в одном месте: посещаемость, прогресс учеников, обращения в поддержку и быстрый доступ к курсам, чатам и материалам.
В исходной версии платформы преподаватель мог редактировать, дублировать и удалять опубликованные курсы. Было решено отказаться от этой модели.
Опубликованный курс — это уже часть связанной системы: расписание, студенты, оплаты и условия записи зависят от его состояния. Любое прямое изменение превращается в риск для данных и пользовательского опыта.
Поэтому административные действия были вынесены на уровень школы и администратора, а интерфейс преподавателя сфокусирован только на операционной работе. Вместо них в кабинете появилась панель сигналов: «Нет расписания», «Низкая посещаемость (ниже 70%)», «Требует подтверждения расписания».
Если три и больше пунктов совпадают — у вас каталог.
Хотите разобраться, каких модулей не хватает в кабинете исполнителя вашего EdTech-маркетплейса? - Напишите нам.