Все статьи

Операции образовательных программ в GetCourse

Три тарифа — не три копии курса

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

MP
Max PerfiljevFounder & CEO, AES · Архитектор автономных организаций
Read in English

Это проектный разбор на основе документации GetCourse, проверенной 24 октября 2026 года. Это не внедрение AES и не заявление о достигнутой экономии. Тезис уже: если несколько платных тарифов используют один учебный материал, тариф должен менять условия доступа к тренингу, а не создавать его очередную копию.

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

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

Курс — не тариф

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

Это не просто аккуратная настройка. Существование контента и право конкретного ученика пользоваться определёнными частями контента на определённых условиях — разные факты. Первый обычно должен быть стабилен для всех тарифов. Второй — место для коммерческих и операционных различий.

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

Как выглядит разрозненный процесс

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

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

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

Процесс доступа из пяти частей

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

  1. Поддерживайте один канонический тренинг для общей программы. Меняйте в нём учебную структуру, когда меняется само обучение.
  2. Определите продукт, который предоставляет доступ к этому тренингу. Так продаваемая сущность связывается с учебной средой, но продукт не превращается в ещё одну копию курса.
  3. Создайте отдельные предложения для реальных тарифов. Зафиксируйте в них срок доступа и значимые условия: например, сдачу заданий, стоп-уроки, тестовый доступ, видимость ответов других учеников или конкретного преподавателя.
  4. Проведите оплату по настроенному коммерческому сценарию. После принятой оплаты GetCourse документирует завершение заказа и создание связанной покупки. Если продукт предоставляет доступ к тренингу, ученик затем может перейти к тренингу.
  5. Используйте созданную покупку и настроенные для неё условия доступа как операционную опору для открытия доступа и отправки инструкций ученику. Случаи вне стандартного маршрута оставьте на проверку людям.

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

Статус оплаты и условия доступа — разные решения

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

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

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

Не переписывайте действующие условия доступа

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

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

Польза — в читаемом коммерческом обещании

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

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

Первичная документация: GetCourse, «Доступ к тренингу через продукт и предложения», https://getcourse.io/blog/771697; «Настройки предложения», https://getcourse.io/blog/767958; «Заказ и покупка после оплаты», https://getcourse.io/blog/758456; «Принятие ручного платежа», https://getcourse.io/blog/761890; «Временный доступ после частичной оплаты», https://getcourse.io/blog/755629. Документация проверена 24 октября 2026 года.

ПОСТРОИТЬ С AES

Превратите архитектуру в работающую компанию.

AES связывает стратегию, задачи, организационную память, знания, агентов, людей и согласования в единой среде исполнения.