Reusable Course Architecture: One Module, Five Client Variants
Getting course template structure right is what separates a training provider who can take on a sixth client from one who cannot. The failure pattern is consistent: a good course gets sold to a second client, someone copies it and edits the examples, and two years later there are five near-identical courses that have drifted apart and nobody dares update any of them. The fix is architectural, and it needs deciding before the second client rather than after the fifth. The Core Principle 🖥️ Sign In to Access Your Dashboard What Actually Varies Between Clients Audit five versions of the same course and the differences almost always fall into four buckets. Examples and scenarios: The concept is identical; the illustration is industry-specific. A data protection module explains the same principles whether the client is a bank or a hospital, but the scenarios differ. Terminology: One client says “incident”, another says “event”, a third says “case”. Purely cosmetic and endlessly disruptive when handled by copying. Policy thresholds: Escalation timeframes, approval limits, and reporting windows differ by organisation. The rule structure is shared; the numbers are not. Branding: Logo, colours, and tone. Notice what is not on the list. The underlying concepts, the learning outcomes, the assessment logic, and the module sequence are usually identical. That identical portion is typically 70 to 85% of the course, and it is what should live in one place. Element Shared Varies by client Learning outcomes Yes Rarely Module sequence Yes Rarely Core explanation Yes No Examples and scenarios No Yes Terminology No Yes Policy thresholds No Yes Assessment structure Yes No Assessment content Partly Threshold items Branding No Yes The Architecture That Works Three layers. Core: The concepts, outcomes, sequence, and assessment structure. One copy, shared by every client. Changes here propagate everywhere. Variant configuration: A set of values per client: terminology mappings, threshold numbers, industry context, and branding. This is data, not content, and it should be editable by an account manager rather than requiring a course rebuild. Client-specific additions: Genuinely bespoke modules that exist for one client only. Keep these small and separate, because they are the part that does not benefit from the architecture. The discipline is resisting the pull toward the third layer. A request that looks bespoke is usually a variant configuration in disguise, and treating it as bespoke is how you end up with five copies again. Designing Content That Tolerates Variation Writing core content that works across clients requires a few habits. Write the principle, then the example: Structure each section so the concept stands alone and the illustration is clearly separable. If removing the example breaks the explanation, the two are entangled. Avoid embedding numbers in prose: “Escalate within four hours” hard-codes a threshold. “Escalate within the defined timeframe, which for your organisation is four hours” separates rule from value. Use consistent internal terminology in the core: Map to client terms at the variant layer rather than writing client language into shared content. Keep assessment items threshold-aware: An item testing a policy threshold must pull the value from the variant configuration, or it will be wrong for four clients out of five. These are the same disciplines that make content maintainable generally, and they connect to the source-linked approach described in migrating a legacy SCORM library. 📄 Generate a Free PDF Sample Course in Your Cloned Voice Testing the Architecture There is one test, and it is decisive. Make a substantive change to the shared core, then check whether it appears in every client variant without anyone touching them. If it does, the architecture holds. If you find yourself opening each variant to apply the change, you have five copies with extra steps, and you will get drift regardless of intent. Run this test deliberately before the third client onboards. It is much cheaper to discover the problem then than at the eighth. Handling the Genuinely Bespoke Request Some requests really are client-specific. A regulated client needs an additional module covering their sector’s requirements, and no other client wants it. Handle these as separate modules appended to the shared programme rather than as modifications to it. The client’s course becomes core plus variant configuration plus one bespoke module, and the core stays clean. Price bespoke modules separately and explicitly. Providers who absorb these into the standard fee end up maintaining custom content at no margin, which is a slow problem that compounds. The build-buy-generate decision for regulated content is covered in custom compliance eLearning. The Cost of Producing Variants To be clear about scope: architecture is a design decision, not a product feature. A well-structured course library is possible in most systems and impossible to retrofit cheaply in any of them. What generation changes is the cost of producing variants. Where variant configuration drives generation, a new client’s version is produced from the shared core plus their values rather than being copied and edited, which removes the specific action that causes drift. For a provider serving five clients with a shared programme Metric Before After Copies of the course maintained 5 1 core, 5 configs Time to apply a core content change 5 edits, 2 days 1 edit, propagates Time to onboard a sixth client 2 weeks 1 day Variants that had drifted from core 4 of 5 0 Restructuring an Existing Course Library Frequently Asked Questions If you are about to sell the same course to a third client, fix the architecture now. The cost of doing it later scales with the number of copies. 👉 Book a Live Platform Demo with an EdTech Expert