Client Experience · Shipped Q2 2026
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.
At a glance
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
The problem
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
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
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
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.
Discovery
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: mapping the full claim journey across client, provider, and system layers to identify where things broke down
Cross-functional workshop: surfacing top billing questions, CS team feedback, and key design questions before scope was locked
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
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.
Billing comprehension survey
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
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.
Synthesizing findings
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 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.
Sharing the vision
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.
Layer 1
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 9Layer 2
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
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 alignedDesigns — Phase 1
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: 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.
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.
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.
Interactive prototype
Click through the claim states, explore the charge breakdown, and see how the page handles pending vs. processed sessions.
Designs — Phase 2
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.
Client asks about a recent insurance change; the agent responds with context about the pending claim
The agent guides a client through updating their insurance card, resolving the issue without a support ticket
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.
Results
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.
Learnings
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.
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.
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.