Building a Client Training Portal for Corporate Training Providers
How to give every corporate client its own branded space on one training platform: tenant structure, seats, manager reports, single sign-on, invoicing and one course catalog reused across clients.

A training provider with three corporate clients can manage on one LMS and a spreadsheet of who bought what. At ten clients, each wants its logo on the login page, its own list of people, a report the HR manager can pull without emailing you and an invoice with a purchase order number on it. A client training portal gives every client that private corner while you keep a single catalog of courses.
The first decision is structural and hard to reverse, so it comes first. The features follow from it.
Decide how the client training portal separates clients
There are three ways to keep one client's people and results apart from another's.
| Model | How it works | Fits when | Watch for |
|---|---|---|---|
| Groups in one LMS | Each client is a group with its own manager. LearnDash Groups with Group Leaders, or Moodle cohorts and groups | Clients accept your branding with a light touch of theirs, and you want to launch soon | Every screen and report must filter by group. One missed filter shows a manager another client's staff |
| One site per client | A WordPress multisite network or separate LMS installs, one for each client | A few large clients with deep customization or contracts that demand isolation | Courses are copied to every site, updates multiply and cross-client reporting is hard |
| Multi-tenant platform | One application where every record carries a tenant. Moodle Workplace, IOMAD or a custom build | Many clients, self-service onboarding, branding and sign-in settings per client | More to build or license, and tenant isolation needs its own tests |
Many providers start with groups and move to tenants once clients ask for things the group model cannot give. Multi-tenancy in Moodle is a feature of Moodle Workplace, which is sold through Moodle's partner network, as the Moodle multi-tenancy documentation explains. If you are weighing a custom build, the database options are in our article on multi-tenancy models in SaaS.
Brand each client without forking the code
Per-client branding should be data, not a copy of the theme. Store a small set of settings for each client and have one theme read them:
- logo, two or three colors and a login page image
- a subdomain such as
acme.yourtraining.com, or the client's own domain - the sender name and footer on emails
- a certificate template with the client's logo and signatory
Resist requests for free-form custom CSS for each client. It turns every theme update into ten rounds of testing. If you offer client-owned domains, plan how TLS certificates are issued and renewed automatically, because doing that by hand stops scaling very early.
Sell seats, not logins
Corporate clients buy a number of places on a course or a bundle. The portal has to keep count without your help. Settle these rules before anything is built:
- When a seat is used. On invitation, on first login or on starting the course. First login is the usual compromise, because it does not charge clients for staff who never showed up.
- How managers fill seats. Individual email invitations, a CSV upload and an enrollment link or code for teams that will not send you a list.
- Whether a seat can be reassigned. A common rule: yes, until the learner has started.
- When seats expire, and what a learner keeps afterwards, such as their certificate.
- What happens at zero. The manager sees a clear message and a way to request more, not an error.
Keep a history of every seat: who assigned it, to whom and when. That log settles billing questions in minutes. For the WordPress version of this setup, see selling courses to companies with LearnDash Groups.
Give managers reports they can pull themselves
A client's training manager asks the same things every month: who has not started, who is overdue, who finished and whose certificate is about to expire. If the answer is an email to you, your support load grows with every sale.
A workable manager area has one table of learners with status, last activity, score and completion date for each course, filters for team or location, and a CSV export. Add a scheduled email of that export and most requests stop. Moodle's custom reports can be scheduled this way, and on WordPress it is a modest custom feature.
The scope rule matters more than the charts. A manager must see only their own organization's learners, and that limit has to be enforced in the query on the server, not by hiding rows in the browser. Test it by logging in as a manager of client A and requesting client B's export address directly.
Single sign-on and provisioning, client by client
Larger clients will ask for single sign-on so that staff use their work account. In practice that means SAML 2.0 or OpenID Connect, and it means each client has its own identity provider. The portal therefore needs sign-in settings stored for each client, not one global setting.
- Routing: decide how a visitor reaches the right login, by subdomain or by the domain of their email address.
- Account creation: create the learner on first sign-in and attach them to the right client, with name, email and department mapped from what the identity provider sends.
- Leavers: when someone leaves the client, their access should end. That needs a provisioning feed such as SCIM, a regular sync or at least a quarterly review with the client.
- Fallback: keep email and password login for small clients that have no identity provider.
Budget time for each SSO connection. The protocol is standard, but every client's IT team has its own form to fill in and its own test window.
Invoicing, purchase orders and renewals
Companies rarely pay by card at a checkout. They ask for a quote, raise a purchase order, receive an invoice and pay by bank transfer some weeks later. A portal built only around card payments forces you to work outside it for your largest sales. It needs:
- an order created by your staff that grants seats before payment arrives
- an invoice carrying the client's PO number, billing entity and tax details
- a payment status you can update when the transfer lands
- renewal reminders to you and the client ahead of seat expiry
- a way to add seats mid-term at an agreed rate
Do not build accounting. Push orders into the accounting system you already use and let it produce the invoice. Keep card checkout as well for small teams who want five seats today.
Reuse one course across many clients
The profit in a training catalog comes from building a course once and delivering it many times. Copying a course for each client destroys that: a correction to one module becomes dozens of edits.
Keep one master course and enroll each client's group in it. When a client wants something of its own, such as a welcome from its director or a policy module, add it as a step visible only to that client's group, or as a short separate course bundled with the master. Decide how updates reach people who are halfway through, since replacing a quiz mid-course can reset their progress.
Some clients will want your course inside their own LMS. You can export a SCORM package, though you lose sight of who completed it. Publishing the course over LTI keeps it on your platform and sends grades back to theirs. Moodle can publish a course as an LTI tool for this.
Plugin, Moodle or custom build
For up to a few dozen clients on a shared catalog, an LMS with groups, seat management and group reports is the sensible start, on LearnDash or on Moodle. Consider a tenant-based platform or a custom SaaS build when clients need their own domains, sign-in and administrators, or when the portal is itself the product you sell. If you can configure groups and reports yourself, do. Bring in developers for seat logic at checkout, SSO for each client, the accounting link and anything touching tenant isolation, because mistakes there expose one client's data to another. We build these systems for coaching and training providers.
Frequently asked questions
Can a client training portal run on WordPress?
Yes, for the groups model. An LMS plugin with groups gives each client a manager, a learner list and progress reports, and custom work adds seats, branding and invoicing. It becomes a stretch when every client needs its own domain, sign-in and administrators.
Do we need a separate site for each corporate client?
Rarely. Separate sites multiply content and maintenance. They are justified when a contract requires physical separation of data, or when one large client wants customization that would not suit anyone else.
How do clients add and remove their own learners?
Through a manager screen with invitations, CSV upload and a deactivate button. Decide whether deactivating a learner returns the seat to the pool, and show the manager the remaining count at all times.
Can clients keep their own LMS and still use our courses?
Yes. A SCORM export runs inside their LMS, while an LTI connection launches the course on your platform from theirs and returns grades. LTI keeps reporting and updates in your hands, which most providers prefer.
Add worldwincoder.com as a preferred source on Google, or open this article in your AI assistant to use it as a source.
