Client portals for AI call reporting

An operator who runs AI phone agents for other businesses eventually faces the same request from every client: show me my calls. A client portal is the structural answer — a branded, read-only surface where each client sees the call history, transcripts, recordings, and outcomes for their own agents, and nothing else. Done well, it replaces monthly report exports with continuous inspection while keeping prompts, billing, credentials, and every other client's data out of reach.

This guide covers the agency problem the portal solves, what a client reporting portal should show and deliberately hide, white-label branding, viewer access models, the discipline that keeps read-only actually read-only, and how recording and consent obligations flow through to portal viewers.

The agency problem: many clients, one operations dashboard

Agencies, answering services, franchisors, and managed-service providers share a topology: one team operates the platform, but the calls belong to many separate businesses. A dental marketing agency might run intake agents for forty practices; an outsourced reception provider might answer for hundreds of small firms.

The operator's dashboard is built for the operator. It exposes agent configuration, prompt text, billing, integrations, and — critically — every client's calls side by side. None of the available workarounds is good:

• Shared dashboard logins leak everything to everyone: one client can read another client's calls, see the operator's prompts and margins, and change configuration by accident or on purpose.
• Manual exports — a weekly spreadsheet or PDF of call summaries — are stale on arrival, omit the audio, and scale linearly with client count.
• Forwarded recordings on request turn every quality question into a support ticket and prove only the calls the operator chose to share.

Delegating calls to an AI agent already asks the client to trust an invisible worker. The remedy is not more assurance; it is inspection. A portal lets each client read what the agent said on their line, hear how it handled a real caller, and watch outcomes accumulate — without inheriting any of the operator's control surface.

What a client reporting portal shows — and what it must hide

The value of a portal is defined as much by its exclusions as its contents. A useful baseline:

Show, scoped to the client's assigned agents:

• Call history: date, direction, calling and called party, status, and duration.
• The transcript of each call.
• Recording playback where a recording exists.
• Which agent handled the call and the graded outcome where the operator grades calls.

Hide, always:

• Prompts and agent configuration. Prompt text is the operator's work product and often encodes commercial logic; it is also the easiest thing for a client to "improve" into a regression.
• Billing, rates, and usage economics between operator and platform.
• API keys, integrations, webhooks, and tool configuration.
• Internal review and issue workflows the operator uses to manage quality.
• Every call that belongs to any other client.

The scoping rule worth insisting on is allowlist by agent: a portal shows calls belonging to an explicit set of assigned agents, and a portal with no assigned agents shows nothing. Deny-by-default fails safe — a newly created agent stays invisible to clients until someone deliberately assigns it — whereas "show everything except…" fails by disclosure.

White-label branding

For an agency, the portal is part of the product it sells, so it should carry the right identity: a logo, brand colors on the sign-in page and portal header, and ideally a custom domain such as calls.clientname.com so the reporting experience never visibly detours through the operator's platform.

White-label call reporting matters commercially, not just cosmetically. An agency reselling AI call handling under its own brand cannot send clients to a third-party domain with a third-party logo without undercutting its positioning. When evaluating platforms, check three levels of branding depth: per-portal logo and accent color, custom hostnames with ownership verification (typically a DNS CNAME plus a TXT verification record), and whether one portal or hostname can be cleanly reassigned when a client relationship ends.

Viewer access models

Portal viewers are people at the client business, so their access should be provisioned per person, not per company:

• Named viewers, added individually. An email address per viewer, so access can be revoked for one departed employee without disturbing anyone else. A shared "client login" recreates the shared-password problem the portal exists to solve.
• Low-friction authentication. Emailed one-time login codes suit occasional viewers; optional passwords suit daily ones; some platforms add single sign-on for larger clients. Short code validity windows limit the value of an intercepted email.
• Deactivation distinct from deletion. Suspending a viewer while preserving the record of who had access is useful during disputes and offboarding.
• Separate sessions. Portal sessions should be independent of the operator's dashboard sessions, so an operator demonstrating a portal is never one shared cookie away from exposing the dashboard.
• A kill switch per portal. Deactivating an entire portal — without deleting its configuration — handles non-payment and contract lapses reversibly.

Read-only scope discipline

"Read-only" is a promise about the platform's authorization model, not about which buttons are visible. The portal surface should be incapable of mutating anything: viewers cannot edit agents, place calls, change routing, manage billing, or touch configuration. If the portal shares an API with the dashboard, the portal's credentials must be scoped so that write endpoints fail, not merely go unlinked.

Scope discipline also means resisting feature creep. Every capability added to a portal — commenting, flagging, requesting changes — expands the attack and confusion surface of a system whose entire design premise is this surface cannot break anything. Operators who want clients in the quality loop are usually better served keeping the portal as evidence and handling change requests through their own channel, backed by regression testing before any client-visible behavior changes ship.

Recording and consent inheritance

A portal does not create new data, but it does create new disclosure. The recordings and transcripts it plays were collected under the operator's recording-consent setup, and showing them to the client business is an additional use of that data. Three obligations flow through:

• Consent posture. Recordings should only exist where the underlying calls were recorded compliantly for the jurisdictions involved; a portal faithfully replays whatever the operator captured, including anything it should not have.
• Retention. Data-retention decisions propagate: when the operator deletes or expires a recording, portal access to it should end with it, and a client who needs longer retention needs that agreed and configured deliberately, not assumed.
• Caller privacy. Callers' personal details land verbatim in transcripts. The client business usually has a legitimate interest in its own callers' calls, but the operator should document that flow in its client agreements and privacy notices. Where calls foreseeably touch regulated data, involve counsel — this guide is general information, not legal advice.

The practical rule: a portal should never widen what is stored, only who may view a scoped slice of it — and the viewing itself should be part of the operator's documented data flow.

On ThunderPhone

ThunderPhone's client portals implement this model as branded, read-only call reporting. Organization admins create portals, each with a client-facing name, a unique URL slug, and an exact set of assigned agents; only calls belonging to an assigned agent are in scope, and a portal with no assigned agents has no visible calls. Branding covers a logo (PNG, JPEG, or WebP up to 2 MB) and a six-digit hex accent color, shown on both the sign-in page and the portal header, plus optional custom domains verified by a CNAME record and a TXT ownership record — a hostname can belong to only one portal.

Viewers are added individually by email and sign in with a six-digit emailed code valid for ten minutes, or a password of at least eight characters they create after signing in; viewers can be deactivated without being removed, portal sessions are separate from dashboard sessions, and a per-portal active switch pauses all viewer access reversibly. Viewers see call date, direction, parties, status, duration, the assigned agent, the graded successful-or-failed outcome where graded, the transcript, and recording playback when a recording is available. The interface exposes no agent prompts, organization settings, keys, billing, tools, or internal issue workflows, and deleting a portal removes viewer access and domain configuration without deleting the organization's agents or calls. Portal administration is also available via API.

Evaluation checklist

When comparing platforms for white-label call reporting:

1. Is call visibility scoped by an explicit agent allowlist that fails closed?
2. Can viewers see transcripts and play recordings, or only summaries?
3. Is branding per portal — logo, colors, custom domain with DNS verification?
4. Are viewers individually provisioned, deactivatable, and on sessions separate from the operator dashboard?
5. Is the portal architecturally read-only, with configuration, billing, and credentials unreachable?
6. Can a whole portal be paused reversibly, and what exactly does deletion remove?
7. Do retention and deletion decisions propagate to what portals can replay?
8. Is there an API for provisioning portals as clients onboard?

FAQ

What is a white-label call reporting portal?

A restricted web surface, carrying the operator's or client's branding, where a client business reviews the calls an AI phone agent handled on its behalf — history, transcripts, recordings, outcomes — without access to the operator's dashboard, configuration, or other clients' data.

Why not just give clients dashboard logins?

Because a dashboard is an operations surface: it exposes prompts, billing, integrations, and every client's calls together, and it can mutate all of them. A portal inverts each property — scoped, branded, read-only, per-client.

Can portal viewers change the agent or place calls?

In a well-designed portal, no. Viewers inspect calls; every write path — editing agents, placing calls, billing, configuration — should be structurally unavailable, not merely hidden.

Do clients see the agent's prompt?

They should not. Prompt text is operator work product, and exposing it invites unreviewed change pressure. Portals should show conversational evidence — transcripts, audio, outcomes — not configuration.

How do recordings in a portal interact with consent requirements?

The portal inherits the operator's obligations: it replays only what was recorded under the operator's consent and retention setup, and sharing that data with the client business is a disclosure the operator should cover in its agreements and notices. Confirm jurisdiction-specific requirements with counsel.

How does a portal fit with quality assurance?

The portal is the client-facing end of a quality pipeline. Operators typically grade calls with call scoring, catch behavior changes with regression testing before deploying, and let the portal show clients the resulting record.