Claims Summary
Led Revv's first AI product initiative end-to-end — from discovery and beta strategy through launch. Uncovering the core insight that reframed everything: shops didn't have a documentation problem; they had a translation problem.
The Results:
$900K+ ARR driven through Claims Builder adoption and Premium tier conversion
78% improvement in claim approval rates for shops using Claims Builder
60% of multi-product users upgraded to Premium tier after adopting Claims products
My Role
UX Researcher
Strategy and Alignment
Design and Execution
The Team
1 Sr. Product Manager
1 Sr. Product Designer
4 Software Engineers
Project Length
1 month - Discovery Calls
3 Months - MVP Build
1 Month - Beta Testing
1 Month - AI Build
Getting Started
We reached out to 100 shops and got 20 on calls.
We expected variation. We didn't get it.
Every shop told the same story — getting paid was a battle. They were burning 45 minutes per claim assembling 20+ page packets, only to get challenged by adjusters anyway.
Rejected claims meant cash flow gaps, frustrated customers, and weeks of back-and-forth to recover money they'd already earned.
Same pain. Every shop. Every conversation.
Nick - Flower Hill Auto Body
"We used to create detailed files, but adjusters frankly didn't care. They just wanted to find the easiest way to check the boxes and decide if they should pay out."
Discovering the real problem
Nick was one of the auto technicians we spoke with, and what he told us changed everything.
We went in expecting to hear about documentation problems. What we found was something more fundamental.
Nick didn't struggle to gather evidence — he struggled to make it land. Adjusters weren't reading through 20-page packets looking for the truth. They were scanning for three things: Is this required? Is it documented? Does the price make sense?
Shops were speaking repair language. Adjusters were speaking insurance language. And nobody was translating.
That insight reframed everything.
The Product Strategy
We had a choice: Work with a third-party tool that customers already used or build something that didn't exist yet.
We decided to build it.
The core idea was a trust translation layer — something that converted complex repair data into language adjusters could act on immediately. No external tool could connect claims data natively to the repair record the way we could. That was our edge.
We baked multi-product adoption directly into the product itself. The more of Revv a shop used — Rate Builder, Workflow, Reports — the stronger their claim file became. Shops weren't just using Claims Builder. They were being pulled deeper into the suite because it made their claims better.
Nothing like this existed in the market. We had a first-mover window — and we moved fast.
Creating Proof of Concept
Mid Fidelity Design
High Fidelity Design
Before committing to a full build, we needed to know if the idea would actually hold up with real users.
In two weeks, we went from concept to high-fidelity MVP — built completely separate from production so we could move fast without risking anything live. Fast enough to feel real. Contained enough to fail safely.
We recruited beta participants straight from our discovery calls. 15 shops accepted. We turned away 20 more who wanted in.
That waitlist told us everything. This wasn't a nice-to-have — shops were hungry for a solution. Over the one-month beta, 80% of participants were actively engaged, not just logging in but mapping journeys with us, flagging friction, and pushing the product in directions we hadn't anticipated. Every session sharpened the build.
By the time we committed to full development, we weren't operating on assumptions. We had signal, we had demand, and we had a product that real users had already helped us make smarter.
Beta Test Learnings
1) Evidence
Evidence documents were still difficult and cumbersome to attach.
Users had a hard time deleting files
2) Scoring System
The 0–100 scoring system was confusing
Complete/Incomplete tags were clearer and more helpful for users
3) Layout
Layout needed to be more readable and scannable
Layout wasn't optimized for how adjusters actually absorb information
4) Share Claims Externally
Adjusters were very hesitant to use the Revv portal on top of all the existing software they had
How might we…
Based on the feedback, I framed five How Might We questions to guide the redesign:
How might we reduce the cognitive load of evidence management?
How might we structure information the way adjusters actually scan and evaluate claims?
How might we let adjusters access and act on a claim without adding another tool to their stack?
How might we make sharing a claim feel safe and final, with zero room for pushback?
Meet the New Design
The redesign came down to one goal: reduce cognitive load.
Applied progressive disclosure to the layout — instead of overwhelming shops with the entire claim at once, the experience reveals one operation at a time, so users move through the file methodically rather than scanning a wall of information
Cleaned up evidence management — shops can now see exactly what's been uploaded per operation and remove anything that doesn't belong with a single click
Built a guest portal for insurance adjusters — a view-only experience accessible without a Revv account, where adjusters can download or print the claim directly
Removed every point of friction — no extra steps, no login walls, no reason for adjusters to push back on the process
The Brain Blast Moment…
The beta gave us learnings. But it also gave me a bigger idea.
Halfway through building Claims Builder, it hit me — everything we needed was already in the platform. Repair estimates, work order notes, technician documentation. We had the whole story. We just weren't telling it.
What if shops didn't have to write any of it?
One button. The AI pulls everything Revv already knows and assembles the claim automatically. No manual writing. No translation required.
The data was there the whole time. We just needed to connect the dots.
This is where Claims Summary AI was born
The Final Design
The final design came down to one interaction: a single button.
Shops no longer had to write the repair summary from scratch. They click "Help Me Write This," and the AI pulls everything already uploaded in our platform — the repair data, position statements, technician notes — and generates a clean, adjuster-ready narrative automatically.
For shops who prefer to write it themselves first, they can do that too. The AI is there to refine, not replace. Either way, the output is structured exactly the way adjusters need to read it.
One constraint worth calling out: we capped the "Try Again" button at 4 attempts per generation. Each output costs us roughly 3 cents to generate — a small number that adds up fast at scale. It was a simple product decision that balanced user flexibility with sustainable unit economics.
Less writing. Less friction. Faster approvals.
Impact
2x increase in claim approval rates — the number that mattered most. We doubled shops' chances of getting paid on the first submission.
90% reduction in claim creation time — from 45 minutes of manual assembly to just a few minutes. Time back on the floor, back on actual repairs.
25% increase in activated contracts — Claims Summary wasn't just serving existing users. It was becoming a reason to sign up.
55% revenue increase from multi-product upsell — shops were buying Rate Builder, Workflow, and Reports to get more out of Claims Summary. The platform wedge worked exactly as designed.
32% decrease in churn — once shops had Claims Summary, they stopped leaving.
Five numbers. One story — Claims Summary AI didn't just improve a workflow. It changed the business outcomes for every shop that used it.
Reflections
What worked — identifying the translation gap was the strategic unlock. It's what made the AI feel purposeful rather than bolted on. Shipping in milestones and validating with real users at every stage kept engineering focused and prevented us from building the wrong thing.
What I'd do differently — the AI was only as good as the data behind it. Shops with incomplete work orders got weaker outputs, and we didn't catch that until they were already mid-claim. I would have built a data completeness check earlier — surfacing those gaps before a shop even started, not halfway through.
The bigger picture — the best tools don't just make processes faster, they change the relationship between the parties involved. When shops had better documentation, the dynamic with adjusters shifted from adversarial to collaborative. They stopped fighting and started just getting paid.