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
- Separate what is stable from what varies. The stable part is the template; the variable part is configuration.
- Four things typically vary by client: examples, terminology, policy thresholds, and branding. Everything else should be shared.
- Copying a course to customise it is the decision that creates the drift problem. Avoid it once and you avoid it permanently.
- A variant should be a set of values, not a duplicate of the content.
- Test the architecture by making a change to the shared core and confirming it reaches every variant.
🖥️ 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
- Audit your existing client versions and sort every difference into the four variance buckets.
- Extract the identical portion into a single core.
- Express the remaining differences as configuration values rather than content edits.
- Rewrite core content to separate principle from example and rule from threshold.
- Test by changing the core and confirming propagation to every variant.
- Keep genuinely bespoke modules separate, and price them separately.
Frequently Asked Questions
By separating a shared core from per-client configuration. Learning outcomes, sequence, core explanation, and assessment structure stay in one place. Examples, terminology, policy thresholds, and branding become configuration values applied at delivery rather than edits to duplicated content.
Four things, consistently: examples and scenarios, terminology, policy thresholds such as escalation timeframes, and branding. The underlying concepts, outcomes, module sequence, and assessment logic are usually identical, typically 70 to 85% of the course.
Because copying a course to customise it creates independent copies with no link back to a source. Someone updates one and the others silently fall behind. The drift is a consequence of the copy decision, not of poor discipline afterwards.
Make a substantive change to the shared core and check whether it appears in every client variant without anyone opening them. If you have to edit each variant individually, you have duplicates rather than an architecture, and drift is inevitable.
No. Keep genuinely client-specific content as separate modules appended to the shared programme, so the core stays clean. Price these separately and explicitly, since providers who absorb bespoke work into a standard fee end up maintaining custom content at no margin.
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.
