Business Process Outsourcers
You run multiple end clients on a shared workforce. Each client has their own service-level expectations, their own brand voice, their own confidentiality clauses, their own reporting cadence — and FrontLine has to make that the default, not the configuration. Tenant → Client → LOB scoping ships as the platform's data primitive. Per-client scorecards, agent assignment without data bleed, audience-scoped client portal, SOC 2 evidence on demand, bilingual EN ↔ FR UI — all of it because multi-client was the design brief, not the use case.
| Capability | FrontLine |
|---|---|
| Multi-client confidentiality enforced at the database (RLS) | Yes — every operational table carries tenant_id + client_account_id with row-level security |
| Per-client scorecards, calibration, and quality reporting | Yes — scorecards scoped per client + LOB; calibration sessions run per cohort |
| Multi-client agent assignment without duplicate employee records | Yes — one agent record carries per-client skills, certifications, and routing eligibility |
| Client portal — read-only, audience-scoped, billable hours from the T&A ledger | Yes — SLA scorecard + billable hours come from the same source as your bill |
| SOC 2 Type II evidence package generation for procurement reviews | Yes — pre-built CSV export per trust criterion (audit Q3 2026) |
| Bilingual platform UI (EN ↔ FR) for cross-border + Canadian operations | Yes — every UI surface renders in the user's locale |
| Per-client compliance posture (PIPEDA, PCI, regulated LOBs) | Yes — retention, audit, and DSAR controls can ride at the client_account level |
The BPO operating model — and what the platform has to make trivial
Multi-client is the architecture, not a feature toggle. Generic HRMS and WFM tools were built assuming one employer with one workforce. When you add a new BPO client, those tools force you to choose between separate instances per client (no shared workforce, separate logins, no consolidated reporting) or one big instance with client-as-a-tag (data leaks every time someone forgets a filter). Neither is acceptable when your MSAs guarantee per-client confidentiality. FrontLine treats tenant → client → LOB scoping as a database primitive — the same way Postgres treats indexes.
The SLA on the client portal has to match the SLA on the bill. Most BPO ops stacks have one source for billing (the time-and-attendance ledger), a different source for client-facing SLA reports (an ops dashboard), and a third for QBR slides (rebuilt manually in PowerPoint). When the three diverge, the client questions the bill and the relationship cracks. FrontLine's client portal reads adherence and billable hours from the same ledger that drives payroll — there's no second source of truth to reconcile.
Client confidentiality is contractual, not a UX preference. Your MSAs commit to per-client isolation: RetailCo cannot see FinCo's roster, agents, schedules, or any cross-account data. Most home-grown portals enforce that scope in application code — easy to forget when an analyst writes a new query and the dropdown silently includes another client's options. RLS pushes that boundary into the database, where the query physically can't return cross-client rows.
SOC 2 is the procurement gate that determines which enterprise clients you can win. US enterprise procurement teams now ask for a Type II report as table stakes — and assembling the evidence quarterly takes weeks of compliance + IT time across multiple disciplines. FrontLine's SOC 2 evidence package generator runs as a one-click export per trust criterion; the audit log itself is immutable by architecture so the auditor can't ask 'is this complete' and get a defensive answer.
If multi-client isn't an architectural primitive, every new client breaks a system.
What FrontLine ships for BPOs
Each capability below maps to an Atlas module you can drill into. The architecture isn't reverse-engineered from BPO use cases — it was the design brief.
Tenant → Client → LOB scoping at the database
Every operational table carries tenant_id (your BPO), client_account_id (your end client), and client_lob_id (line of business). PostgreSQL RLS policies enforce isolation; cross-client queries return zero rows at the database, not in application code. JWT carries the tenant context immutably within each request. The MSA confidentiality clause becomes a database-layer guarantee.
Explore the modulePer-client scorecards + calibration
Scorecards scoped per client + LOB. FinCo gets a regulated 12-item form; RetailCo gets a 5-item conversation form. Calibration sessions run per client cohort so per-client evaluator drift surfaces before it skews the published QA number. Reporting respects the structure — no workforce-wide average hiding which client is bleeding.
Explore the moduleMulti-client agent assignment without data bleed
One agent record carries per-client skills, certifications, and LOB eligibility. The scheduler enforces eligibility at publish time — an agent only appears on shifts for clients they're certified for. No duplicate rosters, no parallel skill matrices, no reconciliation work when an agent picks up a second client.
Explore the moduleClient portal — SLA, billable hours, agent activity
Your end client logs in and sees their adherence scorecard, billable hours by LOB, three pre-built reports, and audience-scoped knowledge articles. They never see other clients' data, agent names, internal pricing, or your roster. Same scoping the rest of the platform uses; nothing manual to lock down.
Explore the moduleSOC 2 Type II evidence package
ZIP export per period with one CSV per trust services criterion (CC6, CC7, CC9, A1). Period-bounded; covers the audit-event prefixes the auditor's workpapers expect. Generation itself emits a CC9 audit event so the chain of custody is intact. The 3-week quarterly evidence scramble becomes a one-click download.
Explore the moduleBilingual platform UI today
Every surface — agent portal, supervisor view, client portal, executive dashboard — renders in EN or FR per the user's locale. For Canadian BPOs serving Quebec accounts or cross-border CA + US workforces, the bilingual UI is the default rather than a paid add-on. Per-content-row EN ↔ FR sibling pairing is on the Atlas roadmap.
Explore the moduleCommon questions from BPO operators
- How many clients can we run on one FrontLine tenant?
- There's no hard cap. FrontLine's architecture treats client_account as a first-class data dimension, not a tag — so adding a new client is a configuration row, not an instance fork. Design-partner BPOs today run 4–12 clients per tenant with multi-LOB structures inside each. Onboarding a new client is part of the normal admin workflow; no engineering involvement needed for routine adds.
- Does the SLA on the client portal match the SLA on the bill?
- Yes — both derive from the same time-and-attendance ledger that drives payroll. There's no second source of truth to reconcile. When your client questions a billable-hours number, the answer is on the next tab of the same portal; when they question adherence, it's the same data joined to the schedule. The reconciliation-during-QBR exercise stops happening.
- Can we white-label the client portal per client?
- Per-client branding (logo, primary colour, contact-email override) is supported today. Custom domains (e.g., portal.yourclient.com) are on the Atlas roadmap — they're the next phase of the client-portal module, scheduled alongside client-self-service configuration. For procurement conversations that require a custom domain on day one, talk to the design-partner team about the rollout timing.
- What about MSA confidentiality between clients — how is that enforced?
- PostgreSQL row-level security policies on tenant_id (your BPO) and client_account_id (the end client) — every operational table. The database physically refuses cross-client queries; there is no application-layer filter for someone to forget. Cross-client probe attempts (JWT tenant_id ≠ resource tenant_id) auto-classify as HIGH severity in the audit log, so attempted breaches are visible before they're incidents.
- How does FrontLine handle our SOC 2 evidence for enterprise procurement reviews?
- The SOC 2 evidence package generator exports a period-bounded ZIP with one CSV per trust services criterion (CC6 Logical Access, CC7 System Operations, CC9 Change Management, A1 Availability). Each CSV is the filtered audit events for that criterion's action prefixes. Your auditor loads it into their workpapers as-is; the same export feeds the enterprise procurement questionnaire that used to chew up two weeks of compliance + IT time.
- Different clients have different compliance regimes (PCI, PIPEDA, regulated LOBs). How is that scoped?
- Compliance controls — PII retention floors, DSAR collectors, audit log scope, retention policies — can ride at either the tenant level (your BPO-wide posture) or the client_account level (per-client requirement). A regulated FinCo client can carry stricter PII handling without forcing it on the RetailCo workforce; the retention engine and DSAR collectors honor both scopes simultaneously.
- Do we need to relabel anything for our specific clients?
- The platform UI labels are configurable per tenant — most BPOs leave them at default ("Client", "LOB", "Agent"). Some relabel "Client" to match their client-facing terminology. The underlying data model and integration contracts (client_account_id, etc.) don't change; the relabel is a presentation-layer choice during onboarding.
Talk to us about your BPO operation
Whether you're a 50-agent shop running a single enterprise contract or a 2,000-agent operation across 8 clients and 30 LOBs, we'll walk through how the architecture maps to your operating model. The platform is built around exactly the operational shape you're running.
Start the conversationRelated solutions
FrontLine for Workforce
FrontLine for QA & Coaching
FrontLine for Clients
FrontLine for Compliance & IT
Technical Support BPOs
Telecom BPOs
Financial Services BPOs