Case study · Enterprise SaaS · 4 Weeks
This overview is intentionally designed for a quick read in under 3 minutes. For the full story, please review the attached case study deck.
Open full case study deck
Why this problem mattered?
At BILL's scale, even a small amount of payment ambiguity creates significant customer anxiety and operational cost. Payment status was one of the largest support drivers, making it difficult for customers to understand where their money was, whether action was required, or if a payment could still be recovered.
Defining the Opportunity
I pulled support ticket data with operations and found that the top five failure types accounted for over 80% of all payment support contacts. The solution couldn’t be a single recovery screen. It had to be a system that could distinguish between failure types, surface the right context, and guide the user to the right action without overwhelming them with technical language.
Designing the Remediation Framework
I designed a four-layer recovery framework: detection and surfacing, a Needs Attention queue, guided remediation flows, and reusable UI patterns. Each failure type had its own resolution flow, reviewed with Operations and Legal to ensure the guidance matched BILL’s real capabilities and compliance requirements.
From Awareness to Action
I designed a four-layer recovery framework: detection and surfacing, a Needs Attention queue, guided remediation flows, and reusable UI patterns. Each failure type had its own resolution flow, reviewed with Operations and Legal to ensure the guidance matched BILL’s real capabilities and compliance requirements.
Design Evolution
The 23% drop in support contacts was measured in the first 60 days post-launch against the prior period baseline. More importantly, the framework became infrastructure for how BILL handles payment recovery at scale — future exception types can now be handled inside the same system without rebuilding from scratch.
Explore more selected work.
Back to work