Sell Three Tiers Without Building Three Courses

This is a workflow design based on GetCourse documentation, verified on October 24, 2026. It is not an AES implementation or a claim of achieved savings. Its argument is narrower: when several paid tiers use the same learning material, the tier should change the access contract around the training—not create another copy of the training itself.

A course team often reaches the same operational fork. One customer buys a self-study tier, another buys a tier with assignments and feedback, and a third gets a defined teacher or a limited preview. The apparently simple response is to create a separate course for each tariff. It feels concrete: each buyer enters the course whose name matches the purchase. It is also how one learning programme quietly becomes three content-maintenance problems.

The stronger design keeps the learning content canonical and makes the commercial entitlement explicit. In GetCourse terms, that means separating the training from the product, the offer, the order and the purchase. These are related records, but they answer different business questions. Collapsing them into several near-identical courses obscures those questions and makes routine change risky.

The course is not the tariff

A training is the learning structure: lessons, tasks and the experience the school intends to teach. A product identifies what is being sold. Offers can express different versions of access to that product. GetCourse documents that a training may be restricted to users who bought a product that grants access, while separate offers for that product can represent different access variants for the same training.

This distinction is more than tidy configuration. It says that “the content exists” and “this learner may use these parts of it under these conditions” are different facts. The first should normally remain stable across tariffs. The second is where commercial and operational variation belongs.

GetCourse documents offer-level settings that can differ while the underlying training remains the same. Depending on the offer, learners can encounter stop-lessons, submit tasks, see other learners’ answers, receive test-drive access, or be assigned to a particular teacher. Duration and access conditions can also be part of the offer design. A school can therefore sell different learning experiences without asking its team to keep separate lesson trees synchronized.

What the fragmented process looks like

Before this separation, an online school may clone a course for every tariff. Each clone receives its own access group, lesson restrictions and communications. Or the team keeps one course but manually puts every buyer into the right group after payment. Both approaches work at small volume; neither makes the commercial promise easy to inspect.

• A lesson correction must be repeated across course copies, and a missed copy creates inconsistent teaching material.
• A new restriction or a teacher assignment becomes a manual access operation rather than a defined term of purchase.
• Support must reconstruct what the learner bought from messages, payment notes, groups and course names.
• An exception can be handled by changing a live setting that also affects customers who bought under earlier terms.

The immediate cost is administrative work. The larger cost is ambiguity. When a learner says, “I cannot submit this assignment,” the team needs to distinguish a configuration defect from an access term that was intentionally sold. Course copies make that distinction harder because content architecture and entitlement history are mixed together.

A five-part access workflow

The practical alternative is not to automate every judgment. It is to give each record a limited job and link them in a predictable sequence.

1. Maintain one canonical training for the shared curriculum. Change the learning structure there when the teaching itself changes.
2. Define a product that grants access to that training. This connects the thing being sold to the learning environment without turning the product into another course copy.
3. Create separate offers for the actual tiers. Put the access duration and relevant conditions there: for example, task submission, stop-lessons, test-drive access, visibility of peer answers, or a particular teacher.
4. Let payment follow the configured commercial flow. After an accepted payment, GetCourse documents the order as completed and creates a linked purchase. Where the product grants training access, the learner can then reach the training.
5. Use the resulting purchase and its configured access conditions as the operational reference for opening access and sending learner instructions. Keep review work for cases that do not fit the standard path.

The consequence is a cleaner answer to a basic support question: what was bought, and what did that purchase open? The answer should not be “whichever course copy someone was added to.” It should be the product and offer connected to a completed order and linked purchase, with access configured for that path.

Payment status and access terms are separate choices

The design also prevents a common shortcut: treating every payment event as identical access. GetCourse documents temporary access after partial payment when that rule is explicitly configured in an offer. This shows that payment state and entitlement terms are separate inputs. A partial payment can lead to temporary access only where the school has deliberately designed that outcome; it is not a universal consequence of receiving money.

Manual payments make the human boundary visible. GetCourse documents that an administrator or manager records a manual payment and marks it accepted. The system can then complete the order and open the access defined by the product. The platform does not replace the person who verifies that the transfer is real, correctly allocated and eligible for the promised tier.

The same boundary applies to refunds, chargebacks and exceptional access. These are not reasons to abandon the model; they are reasons to name an exception path. A responsible operating design assigns people to review the case, determine the appropriate status work, communicate with the learner and make any access change deliberately. It should not assume that every reversal is resolved automatically end to end.

Do not rewrite active access contracts

This structure makes change safer only if the team respects the history already sold. GetCourse warns against changing access settings, or deleting or materially changing products and offers, after sales have begun. Such changes can make active customers lose access or cause restrictions to work incorrectly.

The operating implication is clear: a new tariff, duration or access rule should usually be introduced as a new, reviewed configuration for future sales—not by silently rewriting the offer attached to active purchases. The exact release process will vary by school, but its purpose is stable: preserve the access experience that existing customers were sold while allowing a new commercial variant to begin prospectively.

The benefit is a legible commercial promise

This design does not promise a measured reduction in support time or an automatic revenue gain. Those outcomes depend on the current catalogue, integrations, payment mix and exception volume. Its business benefit is architectural and operational: fewer duplicated training structures, a clearer relation between a purchase and the access it grants, and less reason to administer ordinary access one learner at a time.

For a programme owner, the practical test is simple. Pick one curriculum currently sold in more than one tier. List what is genuinely different: content, access duration, feedback rights, lesson restrictions, teacher assignment, or payment conditions. If the curriculum is the same, keep one training. Put the commercial differences into reviewed offers and access settings. Then reserve people for teaching, payment verification and exceptions—the work that actually requires judgment.

Primary documentation: GetCourse, “Access to training through a product and offers,” https://getcourse.io/blog/771697; “Offer settings,” https://getcourse.io/blog/767958; “Order and purchase after payment,” https://getcourse.io/blog/758456; “Manual payment acceptance,” https://getcourse.io/blog/761890; “Temporary access after partial payment,” https://getcourse.io/blog/755629. Documentation verified October 24, 2026.