Multi-Brand & Shared-Services Contact Centres
You're not a BPO — but you operate like one. A bank's shared-services centre handling retail, credit cards, mortgages, and wealth as four operationally separate businesses. A multi-brand insurance carrier running parent + acquired brands through one workforce. A government department serving three agencies from one floor. FrontLine is the workforce platform built around that operational shape — where the legal model differs but the structural problem is identical.
| Capability | FrontLine |
|---|---|
| Per-brand or per-business-unit data isolation enforced at the database | Yes — Tenant → Client → LOB scoping ships as the platform default |
| Per-brand QA scorecards, calibration, and reporting | Yes — scorecards scoped per business unit; calibration per cohort |
| Shared workforce with per-brand certification + eligibility | Yes — skills carry brand context; routing eligibility honors it |
| Per-brand executive reporting without spreadsheet stitching | Yes — every report rolls up by tenant, business unit, or LOB |
| Bilingual platform UI (EN ↔ FR) for cross-border or Quebec operations | Yes — every UI surface renders in the user's locale |
| Audit-grade record-change workflow across brands | Yes — approval-gated mutations, per-read PII access log, DSAR workflow |
| SOC 2 Type II evidence package generation | Yes — pre-built CSV export per trust criterion (audit Q3 2026) |
The multi-brand contact-centre operational shape
The data-model problem is identical to a BPO's. A bank's shared-services centre supporting retail, credit cards, mortgages, and wealth has the same structural need a BPO has serving four clients: per-business-unit confidentiality, per-business-unit reporting, per-business-unit scorecards, and a shared workforce that can be deployed across all of them without leaking data sideways. The labels differ — "business unit" instead of "client account" — but the architecture has to be the same.
Generic contact-centre software assumes one company. NICE WFM, Genesys, and the in-house Sharepoint stack all default to one workforce serving one business. Multi-brand operations end up with one of two anti-patterns: separate instances per brand (no shared workforce, no consolidated reporting) or one big instance with brand-as-a-tag (data leaks between brands the first time someone forgets to filter). FrontLine treats brand isolation as a database primitive, not a query-layer filter.
Compliance scope is per-brand, not per-org. A regulated business unit (a bank's wealth desk, a hospital's clinical contact line) often carries stricter PII handling, retention, and audit requirements than the rest of the operation. FrontLine's per-brand scoping means those controls can ride at the business-unit level — the wealth desk's stricter PII policy doesn't have to be imposed on the credit-card team, and the credit-card team's looser one doesn't leak into wealth.
The shared-services centre's QA program needs per-brand calibration. Evaluators who score every brand at the same strictness blur the signal — the brand voice differs, the regulatory floor differs, the customer expectation differs. Per-brand calibration sessions and per-brand scorecards are what make the published QA number defensible at the business-unit's QBR.
The labels differ — 'business unit' instead of 'client account' — but the architecture has to be the same.
What FrontLine ships for multi-brand contact centres
Each capability below maps to an Atlas module you can drill into. The same primitives that ship for BPOs handle the multi-brand case structurally — no rebuild, no separate codebase.
Per-brand data isolation at the database
PostgreSQL row-level security on tenant_id (your org) and client_account_id (your business unit / brand). Cross-brand queries return zero rows at the database, not in application code. Survives the parent-company security review's "prove the bank's retail data can't leak to wealth" probe.
Explore the modulePer-brand QA scorecards + calibration
Scorecards scoped per business unit. The retail credit-card scorecard has its own items, weights, and rubric; the wealth-desk scorecard has its own. Calibration sessions run per cohort so the published QA number for each brand reflects that brand's evaluation discipline, not a workforce-wide average.
Explore the moduleShared workforce with per-brand eligibility
One agent record. Skills, certifications, and brand eligibility carried per agent. The scheduler enforces eligibility when the schedule publishes — an agent only appears on shifts for brands they're certified for. No duplicate rosters, no reconciliation work when an agent picks up a second brand.
Explore the modulePer-brand executive reporting
Every operational report rolls up by tenant, business unit, or LOB. The bank's wealth-desk director sees their own KPI sheet; the bank's CEO sees the consolidated view across all business units. Same data, two roll-ups — neither is rebuilt manually in Excel.
Explore the moduleBilingual platform UI today
Every surface — agent portal, supervisor view, executive dashboard — renders in EN or FR per the user's locale. For Quebec operations and cross-border Canadian + US workforces, the bilingual UI is the default, not an add-on. Per-content-row EN ↔ FR sibling pairing is on the Atlas roadmap.
Explore the moduleAudit-grade record changes
Sensitive record changes (manager assignment, role, pay grade, brand assignment) route through configurable approval workflows. Every PII read writes its own audit event. DSAR and right-to-erasure workflows ship with the platform. The regulator-facing record is built into the operation, not assembled at audit time.
Explore the moduleCommon questions from contact-centre operators
- We're not a BPO. Does FrontLine actually fit our shape?
- If you run more than one brand, business unit, or client on a shared workforce, then yes — your operational shape matches what FrontLine is architected around. The Tenant → Client → LOB scoping that BPOs use to isolate end-customer accounts is the same primitive a shared-services centre uses to isolate internal business units. The product doesn't need to be renamed to fit; the marketing copy refers to BPOs because that's our headline market, but the architecture is shape-driven, not industry-driven.
- Our 'clients' are internal business units. Do we need to call them clients in the platform?
- The data model uses client_account_id as the column name; the UI labels are configurable per tenant. Most shared-services centres relabel "Client Account" as "Business Unit" or "Brand" in the UI during onboarding and the rest of the platform follows. The underlying RLS isolation, per-brand scorecards, and reporting roll-ups all work identically regardless of the label.
- We're running parent brand + three acquired regional brands on one workforce. How does this map?
- Each brand becomes a client_account in FrontLine. Agents carry per-brand eligibility (skills, certifications, brand-voice training); the scheduler honors eligibility at publish time. QA scorecards, calibration sessions, knowledge articles, and reporting all scope per brand. The acquired regional brands keep their own KPI sheets without your parent brand seeing them sideways.
- How does compliance scope per brand vs. across the whole organization?
- Compliance controls (PII retention floors, DSAR workflows, audit log scope, SOC 2 evidence packages) can ride at either the tenant level (org-wide) or the client_account level (per business unit). A regulated business unit can carry stricter PII handling without forcing it on the rest of the operation. The retention engine and DSAR collectors honor both scopes.
- Do we need the client portal if our 'clients' are internal?
- It depends. If your business-unit directors are inside the same tenant, they can access reporting directly through the operations surfaces — no portal needed. If you want internal business-unit leadership to log in with a restricted view (only their unit's data, opaque agent identifiers, no other unit's metrics), the client portal works for that scenario as well. Most shared-services centres start without the portal and add it when a business-unit director asks for self-serve access.
- Will FrontLine be renamed or re-branded for non-BPO buyers?
- The product won't be renamed. The marketing site uses 'BPO' as the headline category because that's the market we lead in, and this Contact Centre page is the explicit invitation for multi-brand / shared-services / captive buyers to the same product. The tenant-side UI labels ("Client Account" → "Business Unit", "client portal" → "internal portal") are configurable per tenant during onboarding.
- What about CCaaS integration with our existing Genesys / NICE / Cisco stack?
- FrontLine sits next to your CCaaS, not instead of it. Adherence ingestion from CCaaS into FrontLine is supported via a standard contract (spec 23A). Schedule push to specific CCaaS vendors via turnkey connectors is on the Atlas roadmap (spec 44). For the wiring timing on a specific vendor, ask us on the fit call — the design-partner team works with you on which integration path is shortest for your stack.
Talk to us about your multi-brand contact centre
Whether you're a bank's shared-services centre, a multi-brand insurance carrier, a government department's captive operations, or any other contact centre that serves more than one brand or business unit on a shared workforce, we'll walk through how the architecture maps to your operation — using your labels, your business units, and your compliance posture.
Start the conversation