How one company runs an academy for fifteen client organisations

A training company running an academy for fifteen client organisations is running sixteen organisations, not one. Each client wants its own branding, its own domain, its own administrators and its own reporting. The company wants one place to author a course and one view across all fifteen. Those two wants pull in opposite directions, and the whole design comes down to a single line: content flows down the tree, people and results never move sideways across it.

Put that line in the wrong place and the symptoms are predictable. Either you are keeping fifteen copies of the same course in step by hand every time a regulation changes, or a client administrator opens a report and finds another client's staff in it. The first is expensive. The second ends the contract.

The structure is plain: one parent organisation — the training company — and fifteen client organisations inside it, each free to contain its own sites or departments.

Training company (parent)      authors everything, sees everything
├── Client 1                   learn.client1.com · own admins · own report
│   ├── Operations
│   └── Retail network
├── Client 2                   academy.client2.io · own admins · own report
├── …
└── Client 15                  academy.client15.co · own admins · own report

Sixteen nodes, one installation, one upgrade cycle. The diagram is the easy part. Who edits the fire-safety course? Who sees the completion figures for client 7? What happens when client 3 wants a different pass mark? Those three questions are the whole job.

What is shared and what is separated

Two lists. Almost every operational argument here is a disagreement about which list something belongs on. Shared down the tree, one copy, maintained by the provider:

• Programmes, modules and lessons, authored once at the parent.
• The question bank and the assessments built from it — fifteen copies of a question is fifteen chances for the answer key to drift.
• Competency frameworks, so competent at manual handling means the same thing in every client organisation.
• Certificate templates — the layout, the validity rules, the public verification page.
• The things you never want to vary: retention rules, the audit log, the upgrade cycle, the accessibility work.

Separated sideways, one per client, never pooled:

• Users and their sign-in. A person belongs to one client organisation.
• Enrolments, progress, attempts, grades, certificates issued.
• Branding, and the domain a client's staff type into a browser.
• Administrators, and the roles that give them their rights.
• Reporting scope — every number a client sees is bounded by their own node.
• The address notifications are sent from, so reminders reach a client's staff from the client's own domain.
• Consent records, and anything the client's legal team is answerable for.

Then there is the awkward middle: things that look like content but carry a client's identity. A certificate is the clearest case. The layout, the validity period and the verification page are yours; the logo, the signatory and the organisation named on it belong to the client. A platform that treats a certificate as one indivisible object makes you fork the template fifteen times to change a logo. The rule that keeps you out of that: branding is configuration on the client's node, never a copy of the content. White-label is a configuration surface, not an authoring one.

Authoring once, deploying to fifteen clients

The parent organisation holds the master library. A course is written there, reviewed there and published there. What happens next is where platforms differ, and there are only two mechanisms.

1. By reference. The client organisation is granted access to the parent's course. There is still one copy, so a typo you fix reaches every client the moment you publish. Enrolments and results still sit in the client's node, because those were never shared.
2. By copy. The course is deep-copied into the client's node — modules, lessons, questions, settings. The client now has a separate object that can change independently, and nothing you do upstream ever reaches it again. A real programme is a large object, so that copy runs as a background job.

Reference is the default, and leaving it should feel uncomfortable. Once a course exists in fifteen copies, next year's regulatory update is fifteen edits, fifteen reviews and fifteen chances to miss one.

When a client asks for a change to a shared course

This is the request that decides how expensive year three is. It arrives informally — can you add our incident reporting process to module 3 — and there are four honest answers to it.

1. It is a correction. The content is wrong, or out of date, for everybody. Fix the master and every client has it. More requests are secretly this one than providers expect, and the client who spotted it is usually right.
2. It is presentation. They want their logo, their colours, their terminology. None of that is content. It is configuration on their node, and if the platform makes you fork a course to change a logo, that is the platform's fault, not the request's.
3. It is additive. They want something extra, not something different — the answer most providers miss. Put a client-only module in their own organisation, beside the shared programme. The shared course stays shared, and the client can often maintain the extra material.
4. It is a genuine divergence. Their regulator sets the pass mark at 80 where yours is 70. Now you fork — and the fork gets a date, an owner and a line in a register, because in eighteen months somebody will ask why client 9's version differs, and I think a client asked for it is not an answer.

Access: their administrators, their people, nobody else's

A client administrator has a narrow job: add and remove their own staff, enrol them, chase the ones who have not finished, and pull a report their board will accept. All of it without emailing you, none of it outside their own organisation.

What makes that cheap is scope that cascades: grant a role at a node and it applies to everything beneath it. A client's training director is one grant at the client organisation, and their departments are included automatically. A site manager is one grant at the site. When a department closes you remove the node rather than hunt for grants that outlived it.

The harder half is your own staff, not theirs. Your authoring team works across every client's content and has no business reading learner records. The account manager for clients 1 to 5 needs their results and nothing from clients 6 to 15. A single administrator role at the parent hands everyone everything, which is how a provider ends up with a dozen people who could export any client's staff list. Custom roles built from a permission catalogue, granted at the right node, cost an afternoon.

Reporting, from both sides

What the client sees

Their own people and nobody else's: who is enrolled, who has finished, who is overdue, who failed an assessment twice — broken down by their departments, exportable, on their own branding. The scope of that report is the same node boundary that protects them, so there is one mechanism doing both jobs rather than a security model and a reporting model that have to agree.

What you see

Every node at once. The numbers you run the business on are cross-client and invisible from inside any single client: which clients have enrolled nobody in six weeks, which are near their contracted seat count, which course is failing everywhere and therefore has a content problem rather than a client problem. That last one is the strongest argument for one tenant over fifteen separate installations, where the same pattern is a spreadsheet somebody rebuilds each quarter, if at all.

The tempting next feature is benchmarking: telling client 4 they are in the top quartile. Settle two things first. Contractually, whether each client agreed their aggregate results may be compared with other organisations. Technically, a minimum group size, so a comparison across a few small clients cannot be reversed into a statement about one of them.

Where Lurno sits, and what structure does not solve

Lurno is built for this shape. An organisation contains sub-organisations, each with its own branding and its own custom domain with automatic TLS, so a client's staff sign in at the client's address. Inside an organisation there is a second tree of branches for that client's sites and departments, and a role granted at a branch cascades down it. Content is authored once at the parent, then shared to a client organisation or deep-copied into it.

The tenant boundary is enforced in Postgres rather than in application code: separation enforced underneath the platform. An endpoint that forgets its filter returns nothing instead of somebody else's staff — the claim worth testing with any vendor, ours included. One shape this already runs, without naming anybody: a corporate academy running training for 15 client companies from one tenant.

Four things are not fixed by getting the tree right. Stated here for Lurno; ask the same four of anyone else.

• Billing the client. Payments and checkout are in development. A client is invoiced outside the platform today and the platform records what they are entitled to. That matches how the money already moves for most providers, but card payment at the point of enrolment is a conversation rather than a feature.
• Getting people in. Accounts are created by invitation; self-serve signup is in development. The practical answer is a client administrator who imports their own people instead of sending you a spreadsheet.
• Authentication. Partner sign-on (silent SSO) is available: a client's own system hands a user across with a signed assertion. SAML and OIDC are on the roadmap and not shipped. If a client's IT department has already decided how their staff authenticate, ask in the first meeting rather than the fifth.
• Standards. SCORM, xAPI and LTI are modelled in the product but the runtime is in development. A client who insists on bringing their own SCORM packages is gated on that, and it needs saying early.

The provider-side version of this model is set out on training providers. The internal version — where the sub-organisations are your own regions rather than another company — is on corporate.

The short version

Share content down the tree. Separate people, results, branding and reporting sideways. Reference a shared course rather than copy it, and treat every fork as a decision somebody signed. Give each client an administrator scoped to their own node, and find out where that scope is enforced. Then build your own view across all sixteen nodes: the questions that keep the business alive — which client has gone quiet, which course fails everywhere — can only be asked from the top.