Client-Branded Portals: Running Separate Environments for Enterprise Accounts
A client branded learning portal is the point at which a training provider stops looking like a supplier and starts looking like part of the client’s own infrastructure. It is also the point at which operational complexity multiplies, because four clients means four domains, four sets of branding, four reporting cadences, and four data boundaries you must be able to demonstrate. Getting the pattern right early, including how the AI Coach is scoped per portal, is much cheaper than untangling it at eight clients. Key Takeaways 🖥️ Sign In to Access Your Dashboard What Each Client Portal Needs Five layers, and they are configured separately per client. Domain: Either a subdomain of yours (acme.yourfirm.com) or a subdomain of theirs (learning.acme.com) pointed at your platform. The second reads better to their employees and requires DNS cooperation from their IT team, which is worth requesting during onboarding rather than after launch. Branding: Their logo, colours, and login screen. This is the easy layer and the one demos focus on. Sender identity: Enrolment and reminder emails should come from an address their learners recognise. This requires SPF, DKIM and DMARC alignment against whichever domain sends. Get it wrong and your reminders land in spam, which silently destroys completion rates. Content scope: Which courses this client can see. Usually a subset of your library plus anything built specifically for them. Reporting: Their cadence, their format, their metrics. Different clients want different things, and standardising this early saves considerable time later. Data Separation You Can Actually Demonstrate Enterprise procurement will ask how you guarantee their learner data is not visible to other clients. “It is configured correctly” is not an answer that survives a security review. What they want to see: Write these five answers once, keep them current, and attach them to every proposal. Providers who assemble this per deal lose weeks. Question Weak answer Answer that passes review How is data separated? Each client has their own portal Row-level tenant isolation enforced at the query layer Who can see across clients? Only admins Two named roles, all cross-tenant access logged What happens on exit? We delete it Full export within 14 days, deletion within 30, confirmed in writing SSO Is the Adoption Lever In enterprise accounts, whether learners must remember a separate password largely determines whether they log in at all. Single sign-on against the client’s identity provider removes that friction. It is also the most common reason a launch slips, because it requires coordination with an IT team that has other priorities. Raise it in week one of onboarding, not week five. Practical notes. Most enterprise clients in the GCC use Microsoft Entra ID or Okta, and SAML 2.0 covers the majority of cases. Ask early whether they require just-in-time provisioning, since that changes how enrolment works. And always keep a non-SSO fallback for contractors and external learners, who frequently sit outside the client’s directory. 📄 Generate a Free PDF Sample Course in Your Cloned Voice Build a Launch Template The first portal takes weeks. The fourth should take a day, and it only will if you templatise. Your template should cover: DNS records to request, branding assets to collect, the SSO information checklist, default course scope, the reporting schedule, and a test plan. Package it as a single onboarding document you send the client’s IT contact at kickoff. The test plan matters most. Before any client portal goes live, verify: login via SSO and via fallback, an enrolment email arriving in the inbox rather than spam, certificate generation with the correct branding, a report export containing only this client’s learners, and the mobile experience. Those five catch most launch failures. The wider implementation arc is set out in what happens in the first 30 days. The Support Load Across Portals To be clear about scope: Vocaliv is not your system of record. Learner accounts, enrolments, and completion evidence stay in your LMS, and tenancy separation is a property of that system. What changes is the per-portal support burden. Four portals normally means four support queues, and that is where the margin on a multi-client model disappears. Where content questions resolve without an instructor, the queue that scales with client count stops scaling. Course content is shared across portals from a single source, so an update propagates rather than being repeated four times. For a provider running four client portals, 300 learners Metric Before After Time to launch a new client portal 3 weeks 1 day Support tickets per week across portals 45 14 Course update effort across portals 4 times Once Data separation evidence for procurement Assembled per deal Standing document Launching a Client Portal in Six Steps Frequently Asked Questions If you are about to launch your second client portal, build the template now. Doing it at the fourth means redoing the first three. 👉 Book a Live Platform Demo with an EdTech Expert