Client Experience · Shipped Q2 2026

The billing page that was blocking clients from continuing therapy

Unexpected charges, confusing insurance breakdowns, and no way to get answers after hours. For clients already navigating their mental health, billing confusion was what made them stop showing up. Leadership called it a UX cleanup. My research said it was a retention problem disguised as a support ticket problem. The fix wasn't better copy. It was a completely different information architecture, organized around how clients experience care.

I ran the research, shaped the strategy, and designed the full experience. What started as a backlog item became a multi-quarter, cross-functional commitment: a redesigned billing experience and an AI support agent for the questions no static page can answer.

↓ Jump to solution

At a glance

3,203 billing support contacts/month, the baseline this was built to reduce
69% detractor rate among clients who mentioned billing in NPS surveys Feb 2026 baseline
5% of users in live AI support agent experiment as of Q2 2026

My role

Lead Product Designer

Timeline

Q1–Q2 2026

Team

Florence Vaillant (PM) · Alex Yelskiy + Hash Gari (Eng) · Olivia Laboriel (Dev support)

Tools

Figma · Claude · Amplitude · Coda

Status

Layer 1 shipped June 9 · Agent in experiment · Layer 3 roadmap

Too many support tickets, unhappy clients, and providers getting pulled into billing conversations that had nothing to do with therapy.

SonderMind was generating 3,203 billing support contacts a month. 69% of clients who mentioned billing in NPS surveys were detractors. Providers were fielding billing questions in therapy sessions. Leadership framed it as a UX cleanup. It wasn't.

Business signal

Billing confusion was a retention problem, not a support cost

3,203 billing support contacts per month. 69% detractor rate among clients who mentioned billing in NPS surveys. Clients who can't understand their charges don't rebook. This was a churn driver disguised as a support ticket problem.

Client experience

A session ends. For 45 days, nothing. Then a charge with no explanation.

Clients logged in after their session and saw a blank page, nothing until a charge processed. When a charge appeared, there was no context: no session it mapped to, no explanation of why $175 wasn't the $30 copay they expected. That blank page made clients feel they couldn't trust the company with their money or their care.

Provider impact

Clients were going to their therapists with billing questions. Providers weren't equipped to answer.

Billing friction was bleeding into the therapeutic relationship at exactly the moment when trust matters most. Providers weren't billing experts. Being pulled in as first-line support wasn't fair to them, or to clients.

Learning from SMEs, mapping the client experience, and churning the support data with AI.

Before designing anything, I needed to understand what "confused" actually meant, and whether a better page would even solve it. Several other people had already proposed solutions: better copy, or explaining what a deductible is, or fixing payment processing issues. Those ideas are fine. But they didn't address the source of the problem. They were band-aid fixes.

The lifecycle of a client — full service blueprint mapping pre-claim and post-claim submission flows across client, provider, and system layers

The lifecycle of a client: mapping the full claim journey across client, provider, and system layers to identify where things broke down

FigJam workshop board — top billing questions and features, key design changes, and CS team feedback

Cross-functional workshop: surfacing top billing questions, CS team feedback, and key design questions before scope was locked

AI-assisted research synthesis — Claude analysis of billing contacts alongside Healing the Ledger research document

AI-assisted data analysis: Claude clustering 3,203 support tickets alongside the research framing. The AI surfaced categories. The root causes required human interrogation on top.

Quantitative analysis · 3,203 support tickets + 55 NPS verbatims

AI clustered the data. I interrogated the clusters.

Why this method

3,203 contacts is too large to read manually. AI-assisted clustering was the only way to get full coverage in the time available. I gathered support call transcripts, emails, NPS data, interview notes from support reps, and my own client survey data into NotebookLM, then used Claude to cluster it into themes. But AI surfaces what clients say, not why. That required a second pass before the output was usable.

What was found

Two dominant clusters: "Copay & Payment Confusion" (1,629) and "Card on file errors" (1,442). At surface level, two distinct problems. At root, the same cause: a 45-day information blackout between session and charge.

What it didn't answer

Volume tells you what people call about, not how frustrated they are. And not every frustrated client bothers submitting a support ticket. Some just stop rebooking.

AI override moment: Claude returned "Copay & Payment Confusion" as the primary driver. I rejected that framing and traced each cluster to its origin event. The actual cause, a 45-day information blackout, doesn't appear as a category because clients don't know that's the problem. They describe the symptom. Naming the root cause was the design decision that made everything else work.

Billing comprehension survey

"Covered by insurance" is a phrase that actively misleads clients.

When providers say they "accept insurance" or are "in-network," clients interpret that as "I won't be charged." They don't have a working model of copays vs. deductibles vs. coinsurance. The #1 ask: be able to contact someone immediately when something is confusing. That directly justified the AI support layer.

Competitive analysis · telehealth platforms + insurance portals

Clients already have a mental model for billing. I wanted to meet it, not fight it.

Most telehealth platforms are payment-first. Traditional insurance portals use EOB format: billed vs. allowed vs. patient responsibility. I reviewed my own EOBs and ran a competitive analysis on similar platforms to pressure-test the language. The most useful insight was how to structure the bill info. Clients want to see first and foremost what they owe for their session, if anything. They also want the breakdown: what insurance covered, what their portion was, and why. Seeing what insurance covered confirms their insurance was accepted and used for their therapy session. That became the core of the processed claim card.

Five distinct friction points. One amplifier. And a root cause no one had named.

The data didn't just show what clients were calling about. It revealed a structural problem. The billing page was organized around how the backend worked, not how clients thought. Every friction point traced back to the same source: a 45-day gap between session and charge with no information in between. "Inability to get help" wasn't a sixth problem. It was the amplifier that turned every other problem into churn.

Five distinct friction points drive support volume — donut chart showing Insurance Comprehension 36%, Connecting Charge to Service 23%, Pending Charges 20%, Medicare/Complex 14%, Payment Methods 7%

Five friction points driving 3,203 monthly contacts, with "Inability to Get Help" identified as the amplifier that turns confusion into churn

The comprehension survey revealed something the support tickets couldn't show: the confusion started before clients ever reached the billing page. "Your insurance covers this," language the whole industry uses, was creating wrong expectations from the start. Clients heard "covered" and assumed "free." That's not unreasonable. Most people interact with insurance a handful of times a year. We're so entrenched in it that it's easy to forget it's not like that for most people. That was the framing I brought to the scoping call. We'd built a billing page for people who understood how claims work, and most of the clients we surveyed did not.

No UI is complete enough. Restoring financial trust required three layers.

The longer I spent designing claim states, the clearer it became that there would always be a next edge case. Medicare Advantage. EAP billing cycles. VA authorization windows. The answer wasn't designing more states indefinitely. It was a layered strategy. I presented this to leadership as a pyramid: transparency first, then intelligent support, then proactive communication.

Restoring Financial Trust pyramid — Layer 1 Visibility (Soon), Layer 2 AI Sophistication (Next), Layer 3 Efficiencies and Communication (Future)

Layer 1

Transparency

Redesign the billing page from payment ledger to claim-first session history. Every session visible from the moment a claim is submitted. Charge type labels. Insurance coverage breakdown. Payment method where clients need it.

Shipped June 9

Layer 2

Intelligent support

A context-aware AI support agent, available 24/7, educational, connected to the client's actual claim and insurance data. Resolves questions before they become support tickets.

In experiment (5% of users)

Layer 3

Proactive communication

Eliminate upstream billing confusion before it generates a contact at all. Year-end insurance reminders. Proactive outreach when claims take longer than expected.

Roadmap — leadership aligned

A billing page organized around sessions, not payments

The billing page is now claim-first. Every session is visible from the moment a claim is submitted, not when money moves. Six claim states were designed from scratch to cover the full lifecycle.

Before and after — old payment-first billing page versus new claim-first billing page with full breakdown

Before and after: the old payment-ledger page versus the new claim-first session history

State What it shows Design note
Processing Claim submitted, insurance review in progress. Session visible immediately after claim submission. No timeline visualization; engineering cut this. The status label carries what the animation was supposed to communicate.
Processed Full breakdown: amount billed, insurance covered, charge type label (Copay / Coinsurance / Deductible), patient responsibility. The charge type label is the most important single design decision. It answers the question clients were calling about.
Action Required Specific ask, one direct path to resolve. One action per card. Too many options at a moment of anxiety is its own failure mode.
Denied Denial reason, appeal path. Denial reason language required careful handling. Worked with RevOps on approved language before design was finalized.
Paid Receipt-style confirmation. Definitively closed. The end state clients need to see to trust the system worked.
Upcoming Estimated cost before session. The anxiety lives before the charge, not after. This is where transparency matters most.

01

The charge type label answers the question clients were calling about

Clients were calling because they didn't understand why $175 wasn't the $30 copay they expected. The charge type label, Copay / Coinsurance / Deductible, closes that gap. The comprehension survey showed that "covered by insurance" was actively creating wrong expectations. This label is the correction.

Billing and payment history page showing a processed claim with full breakdown

02

Pending claims are visible from day one

Previously nothing appeared until a charge processed, up to 45 days of silence. Now every session shows a claim card the moment it's submitted. Clients can see their session is in the system, even before insurance adjudicates. This alone addressed 20% of support contacts: the "was my session even recorded?" calls.

Engineering constraint: no timeline visualization. The state machine required more backend plumbing than justified at launch. A status label does the work the animation was supposed to do.

Billing page showing pending claim state

03

The full picture, across device sizes

The redesign needed to work across desktop and mobile, since clients check their billing on both. The claim card layout stacks cleanly on mobile without losing the charge breakdown. EAP and VA clients, who previously saw an empty page, now see sessions with explicit "$0 — Covered" status. Payment method is surfaced directly on relevant claim cards with a direct update link, eliminating 117+ monthly contacts from clients unable to find where to update their card.

Three-screen billing page overview showing desktop and mobile views

Interactive prototype

Try the billing experience yourself

Click through the claim states, explore the charge breakdown, and see how the page handles pending vs. processed sessions.

Open prototype

An AI support agent as the safety net above the UI

The #1 ask in the comprehension survey was immediate access to someone who could explain charges. No matter how complete the billing page is, some questions need conversation, because insurance is too variable, and because anxiety at 10pm doesn't wait for business hours.

04

Context-aware, educational, available 24/7

The agent sits between the static billing page and a human support agent, catching the questions the UI can't fully answer. It's designed to be context-aware (connected to the client's actual claim and insurance data), educational (able to explain what a deductible is in plain language), and always available. 60% of billing questions are educational and can be fully resolved without human escalation.

AI Agents provide instant context and education — diagram showing the agent layer between static design and human support
Billing page with AI agent chat open — client asking about insurance change

Client asks about a recent insurance change; the agent responds with context about the pending claim

AI agent guiding client through insurance card upload

The agent guides a client through updating their insurance card, resolving the issue without a support ticket

SonderMind portal with Sonder AI widget entry point

The agent entry point, surfaced in the portal as Sonder AI, accessible from the billing page

The agent launched with general FAQ capability first, not claims-connected responses. An agent that confidently answers a billing question incorrectly is worse than no agent. It earns personalization by being reliable at the general level first. Currently live for 5% of users (~600 people); the next iteration connects it to real claim and insurance data.

Layer 1 shipped June 9. The 60-day measurement window hasn't closed. Here's what we're tracking and what already changed.

3,203

Billing support contacts/month

Feb 2026 baseline

69%

Detractor rate on billing NPS

Feb 2026 baseline, primary improvement signal

≥10%

Reduction target in billing care coordination cases

Defined success threshold, 60-day window

Pending results!

The page redesign is currently rolled out to 50% of client traffic. The support agent is already intercepting client cost-transparency questions and saving disputes for human CS reps.

What I'd do differently, and what I'd fight to keep

01

AI output is a starting point, not an answer

Claude clustered 3,203 tickets and surfaced "Copay & Payment Confusion" as the top problem. I rejected that framing. The actual cause, a 45-day information blackout, doesn't appear as a category because clients don't know to name it. Interrogating the AI's output instead of accepting it is what turned this from a copy fix into an architectural redesign.

02

Design authority requires domain depth

Multiple XFN teams arrived with symptom-level solutions before the research was done. I used the research to redirect those conversations, not to dismiss the ideas, but to place them in the right order relative to root causes. You can only do that credibly if you know the domain well enough to say "we're solving the wrong thing" and be believed.

Since this project, I ask one question before any scoping conversation: "Are we treating a cause or a symptom?"
03

Know which fights are worth having

I held firm on inverting the data model when engineering pushed back. A claim-first UI on a payment-first backend is a visual trick, not a fix. But I accepted the cut of the claim timeline visualization and VA/EAP authorization data without hesitation. There's a real difference between the architectural decision that makes the system work and the features that can ship in a fast follow. The skill is knowing which is which before the conversation starts.

Next case study

Closing the loop: giving clients visibility into their own progress in therapy

Read it →