FrontLine for Clients — self-serve visibility without giving up your roster.
Your end client wants SLA proof, billable-hours transparency, and agent-activity snapshots on their own time. You want them to stop emailing for weekly status reports. Same portal, no spreadsheets, no roster leak.
Client portal — RetailCo view
RetailCo · Retail support · 247 assigned agents
Schedule adherence
94.2%
Schedule coverage
97.4%
Billable hrs · MTD
9,362
Reports run · MTD
18
Lines of business · this week
L1 retail support · English
L2 escalations · English
L1 retail support · Français
Returns + refunds · English
Recent activity
SLA scorecard refreshed · Adherence 94% · coverage 97% · trending +
2m
Billable hours CSV downloaded · May 1–18 · 12,847 reg + 412 OT + 32 stat
8m
Operations summary report run · Week of May 12 · all 4 LOBs · period: weekly
14m
Knowledge article viewed: return policy v3 · Returns + refunds · published 2026-05-09
21m
Client activity · last 7d
All accounts
RetailCo
4 reports run
12 articles viewedAtlantic
2 reports
8 articlesFinTech
1 report
4 articlesMedTech
0 reports
6 articlesWhat's hard about client visibility at a multi-client BPO
Generic CRMs and account-management tools don't give your end clients self-serve visibility — and the BPOs that have tried home-grown portals usually leak something they shouldn't (other clients' SLAs, agent personal info, internal pricing). Self-serve done wrong is worse than no self-serve.
Weekly status reports eat the account team
Every Friday: SLA screenshots from one tool, billable hours from billing, headcount from HR. Stitched in a deck, sent at 5pm. Three accounts × four hours = an FTE gone to status reporting alone.
Home-grown portals leak the wrong data
Spin up a portal in Retool or Looker. Three weeks later a client_id dropdown silently includes another client's SLA row because the scope check lives in an app-layer JOIN the next analyst forgot to wire.
Don't show your agents' names — show their work
Clients need to know the work got done, the SLA is hit, the hours are billable. Not agent names, emails, HR records. Most dashboards expose all of it because the data model doesn't separate client view from HR view.
QBR slide deck rebuilt every month
Same shape every month — adherence, coverage, billable hours, top performers, top complaints. Rebuilt by hand because the source data lives in five tools and nobody trusts the auto-export.
One client signs an enterprise NDA — and now your tooling is wrong
Enterprise NDA: agent activity, SLAs, billing cannot share infrastructure with other clients. The portal your team spun up for the other six fails the clause — co-mingled data, app-layer scope check. The deal stalls in security review.
"Why was coverage low Tuesday?" goes unanswered
Client sees a coverage dip on the dashboard. The account manager digs: call-out? Forecast variance? Schedule change? The data exists but the portal doesn't surface the why. More emails, more meetings, less trust.
What FrontLine does for your client services team
Six client-portal surfaces designed for multi-client operations from the ground up. The read-only portal + SLA scorecard + billable hours are live today; interactive features (staffing requests, agent ratings, white-label branding) are on the roadmap.
Feature 01
Agent roster + activity drawer — what they did, not who they are
The client sees the agents assigned to their account, an opaque agent identifier (not a name), and a click-through activity drawer with 5 KPIs over any 93-day window. They never see personal information, internal IDs, or other clients' rosters.
- Per-client scoping enforced at the data layer. client_user_account_bindings + employee_client_assignments enforce tenant and client_account scope via row-level security. The client cannot query agents from another account — the database refuses the request.
- 5-KPI activity drawer. Productive hours, attendance rate, QA average score, schedule adherence rate, coaching sessions completed. Per agent, configurable date range, 93-day cap per spec 24A §6.
- No personal data exposed. Agent name, email, employee ID, and HR records stay internal. The client sees an opaque identifier and the work output — nothing more.
- Date-range picker. Client picks any window up to 93 days. Useful for QBR prep without rebuilding the deck.
- Audit-logged. Every drawer open is captured: who, when, which agent. The internal access log surfaces it under spec 36 PII access log.
Agent roster — RetailCo client view
RetailCo · Retail support
247 assigned agents · opaque identifiers only · click any row for activity
Assigned agents
L1 retail · English
ActiveL1 retail · English
ActiveL2 escalations
On breakL1 retail · Français
ActiveReturns + refunds
Off scheduleL1 retail · English
ActiveNo agent names. No emails. No HR records. The client sees the work — not the person.
Feature 02
SLA scorecard — adherence and coverage, automated
Two automated KPIs the client refreshes themselves: schedule adherence % and schedule coverage %. No more screenshots from another tool. No more month-end reconciliation. The number on the scorecard is the same number on your bill.
- Schedule adherence %. Actual logged hours divided by scheduled hours, per agent and rolled up per account. Sourced from spec 23 workforce schedule + spec 23D time-and-attendance actuals.
- Schedule coverage %. Scheduled hours divided by forecast-required hours, per account. Surfaces under-staffing trends the client used to learn about from missed SLA emails.
- Per-account scoping. RetailCo sees RetailCo's scorecard. FinCo sees FinCo's. The database enforces — no application-layer filter to forget.
- Trend on the same screen. 30 / 60 / 90 day trend on each KPI. The client sees if you're improving without asking.
- Tied to bill. Same data source as the billable-hours view below. When the client questions the bill, the answer is on the next tab.
SLA scorecard — RetailCo · May 2026
RetailCo · Retail support
Trailing 30 / 60 / 90 day rollup · refreshed every 15 min
Schedule adherence
≥ 92%94.2%
30d: 93.1 → 94.2 (+1.1)
Schedule coverage
≥ 95%97.4%
30d: 96.8 → 97.4 (+0.6)
Same numbers drive your bill. No reconciliation needed at QBR.
Feature 03
Billable hours — regular, OT, stat-holiday, by account and LOB
The client downloads the same CSV your billing team works from. Regular hours, overtime, statutory holiday — broken out per account and per LOB. No reconciliation between billing-system invoice and operations dashboard.
- Three categories. Regular, overtime, statutory holiday. The same breakdown your contract priced. The client sees what they're paying for.
- By account and LOB. RetailCo English support → 1,247 reg + 84 OT + 16 stat. FinCo compliance → 612 reg + 0 OT + 0 stat. Per LOB if multiple.
- CSV export default-on. One click. The client downloads, opens in Excel, ties it to the invoice. End of negotiation about "what does this number mean."
- Derives from spec 23D actuals. Same time-and-attendance ledger that drives payroll. There's no second source of truth.
Billable hours — RetailCo · May 1–18
RetailCo · Retail support
Period: May 1, 2026 → May 18, 2026 · derived from spec 23D T&A actuals
L1 retail · English
4,212L1 retail · Français
1,847L2 escalations
1,612Returns + refunds
1,247L2 escalations
248L1 retail · English
164All LOBs · May 19
32Total billable
9,362 hrsExport CSV · default-on per spec 24 OD-3
Feature 04
Pre-built reports — operations, QA trend, staffing snapshot
Three reports the client can pull themselves over daily / weekly / monthly periods: Operations Summary, QA Trend, and Staffing Snapshot. CSV export default-on. No rebuild from raw data in Excel.
- Operations Summary. Volumes, AHT, adherence, attendance — the standard weekly ops report. Auto-pulls from the operations data model; no manual aggregation.
- QA Trend. QA scores by week, by section, with drill-down per agent (opaque identifier). Surfaces drift the client used to learn about during the QBR.
- Staffing Snapshot. Headcount on the account by LOB, vs. forecast required. Surfaces under-staffing without the client having to ask.
- Period selector. Daily, weekly, monthly. Up to 90 days back. Per spec 24 OD-3, CSV export is default-on so the data flows into the client's own BI tool.
Reports — RetailCo
RetailCo · Retail support
Period: weekly · last 12 weeks · CSV export default-on
Operations summary
QA trend
Staffing snapshot
Each report exports to CSV in one click — flows into your client's BI tool.
Feature 05
Per-client knowledge access — published articles, audience-scoped
The client browses the published SOPs and policies that apply to their account. Knowledge articles carry an audience filter; the database enforces what the client sees vs. what your other clients see. Same content engine, isolated views.
- Audience-scoped. Articles published with an audience set to RetailCo are only visible to RetailCo client users. Server-side EXISTS subquery enforces — no app-layer filter to forget.
- Published-only. Drafts and archived articles are never visible. The client sees what's been formally reviewed and published.
- Search + browse. Article list with category filter; full article view with version history (for the client to see when policy changed).
- Cross-references the Knowledge persona. Backed by Module 32 authoring API. As Knowledge Management's internal authoring UI ships, content for the client portal flows from the same source.
Knowledge — RetailCo client view
RetailCo · Retail support
Search articles (RetailCo-scoped) …
Return policy v3 (2026-05)
L2 escalation playbook — angry caller
Holiday hours — May 2026
Quebec FR — voice greeting script
Articles audience-scoped per client + LOB. RetailCo never sees FinCo's KB.
Feature 06
Delegated admin — assign and move users across accounts
Your internal account team moves users and employees across client accounts and LOBs from one UI. Every move emits an audit row. MFA-gated. Permissions internal-only — clients never see this surface.
- 8 operations. Assign / unassign / move client users across accounts; assign / unassign / move employees across client accounts and LOBs. Per spec 24 §6 API Baseline.
- MFA + audit per op. Sensitive ops require MFA. Every move is audit-logged with who, when, what — compliant with spec 12 audit model.
- Internal-role gated. Permission keys live in 11A. The client role is locked out of this surface entirely.
- Scoped to the BPO. Your account team sees only the BPO tenant's accounts. Multi-tenant isolation enforced via RLS.
Delegated admin — internal account team view
Client portal admin
Internal account team only · clients never see this surface
Assign user to account
j.tremblay@retailco.com → RetailCo
Move employee across LOBs
AGT-1284 → RetailCo · L2
Unassign user from account
former@retailco.com ← RetailCo
Move employee across accounts
AGT-2298 → FinCo · Compliance
Each op: MFA-gated, audit-logged (who, when, what), permission-checked.
Business outcomes for the people running the BPO
What this looks like in margin terms for the COO or account-management lead.
Account team reclaims a day a week per account
Self-serve SLA, billable hours, and reports retire the weekly status-deck ritual. At 4 hours/week × 3 accounts × 50 weeks, that's 600 hours back — roughly an FTE of account-management capacity recovered per analyst.
Same numbers on the bill, the scorecard, and the QBR
Billable hours, SLA scorecard, and reports all derive from the same operations + T&A ledger. The client stops asking "why does this number not match" because there's only one number.
Zero roster leaks, ever
Row-level isolation enforced at the database. The client query for another account's data physically cannot return rows. Survives the QBR penetration test, the SOC 2 audit, and the enterprise NDA review.
Sign a new enterprise client without a separate portal stack
Tenant + account scoping is the data layer. Adding a new client with a strict NDA is one onboarding row — not a separate portal instance, not a forked codebase.
What client services actually gets back
Directional outcomes in account-management's own units — hours back, reports automated, systems retired.
Per account analyst, every week
Status-deck ritual retired by self-serve SLA + billable hours + reports on the client portal. Magnitude depends on your prior cadence.
Three systems → one portal
SLA dashboard + billing-system export + manual headcount tracker collapse into one client portal with one source of truth.
Billable hours derive from the T&A ledger
The same ledger that drives payroll drives the client portal. No reconciliation between what the client sees and what payroll runs.
Zero cross-account exposure
Per-account RLS in the database. The client physically cannot query another account's agents — enforced at the data layer, not the app layer.
Trust and compliance posture
FrontLine for Clients vs. a home-grown portal
Six things BPO account teams notice in their first month away from Retool / Looker / shared Google Drive folders.
| FrontLine for Clients | Home-grown portal | |
|---|---|---|
Per-account row-level isolation at the database Home-grown portals usually enforce scoping in app code — easy to forget on a new query and accidentally leak another client's data. | ||
SLA scorecard + billable hours derive from the same ledger Home-grown portals stitch from billing-system exports and ops dashboards. Numbers diverge; clients lose trust. | ||
Audit log on every client access Audit logs in home-grown portals usually cover writes, not reads. Spec 36 PII access log captures every drawer open. | ||
Audience-scoped knowledge articles (per account + LOB) Home-grown portals dump a Google Drive folder. FrontLine scopes per account and LOB at the data layer. | ||
Bilingual platform UI (EN ↔ FR) — Law 25 ready Portal UI is fully bilingual today. Same i18n architecture as the rest of FrontLine. | ||
Delegated-admin moves audit-logged + MFA-gated Home-grown portals usually skip MFA on assign/move ops. Spec 12 audit model + MFA gate are non-negotiable here. |
In production today
Client Portal (Module 24) is shipped — read-only portal (agent activity, reports, knowledge) and SLA scorecard + billable hours all live today. Interactive features (staffing requests, agent ratings, white-label branding) are on the roadmap. See the technical detail and feature-level status on the Atlas.
Questions account teams actually ask before signing
Pulled from real fit calls. Short, direct answers.
Our clients can already log into a Looker dashboard. Why move?+
What CAN'T the client see today? Be specific.+
How do we onboard a new enterprise client with a strict NDA?+
Can clients see agent names if we want them to?+
What about the QBR? Is there a pre-built QBR mode?+
What's on the roadmap that I should know about for the conversation?+
Ready to see it in your environment?
Two ways to take the next step.
Other teams using FrontLine
Client Services doesn't live alone. Here's what the rest of FrontLine looks like from the team next door.