The Problem

The carrier was selling product warranties through retail shops, but everything downstream was held together with spreadsheets and manual labor. Three completely different user groups — shop owners selling warranties at the register, insurance teams processing claims, and warranty purchasers occasionally filing — were all being served (badly) by the same broken process.

 

The numbers told the story:

• Claims took an average of 17 days to process — not because the work was hard, but because context kept getting lost during handoffs

• The team was spending 23+ hours a week manually generating reports from data that already existed in spreadsheets

• Support call volume was high enough to be a real staffing problem — mostly routine questions users should have been able to answer themselves

• An internal system had already been built and failed. Adoption was the problem, not just functionality.

 

And the deadline: Christmas shopping season was coming. Warranties sell in volume over the holidays. They needed a working system — one people would actually use — before their busiest period of the year.

​

The Challenge

Three user types. Completely different usage patterns. One system.

​

Shop owners needed speed above everything else — they had customers standing at the register. Insurance teams needed visibility and efficiency across complex internal workflows. Warranty purchasers used the system maybe twice in their lifetime (registration, then a claim), and usually under stress when they did.

​

Designing one experience that served all three without annoying any of them was the real design problem. The previous system had failed partly because it treated these groups the same way.​

​

Research & Discovery

I did weekly check-ins and on-site visits with the alpha customer throughout the project. Interviewed all three user groups. The findings were blunter than I expected.

​

Shop Owners

The previous system died at the register. Warranty registration was too slow — customers were already putting on their coats. Speed wasn't a nice-to-have. It was the whole game.

​

Insurance Teams

The 17-day claims cycle wasn't a volume problem. It was a handoff problem. Processors were passing work to each other without passing context. Every handoff required someone to go back and reconstruct what had already happened. The actual work per claim was a fraction of those 17 days.

​

Warranty Purchasers

Low technical proficiency, high stress when they actually needed the system. Support calls were mostly people asking "where is my claim?" — a question the system should have been answering automatically.

​

The core insight: the previous system had failed because it was built around data structures, not tasks. Users didn't want to navigate a system — they wanted to complete something and get back to work.​

​

Key Design Decisions

Task-Based Homepages Over Navigation

Instead of a traditional menu structure that asked users to remember where things lived, every role got a homepage that showed specifically what needed doing right now. Shop owners saw "Register Warranty." Claims processors saw "Review Claim #1234." Managers saw "Approve Policy Change." Click the task, complete the work, done.

​

This was the fix for the adoption problem. The previous system had failed because users had to figure out what to do next. We removed that decision entirely.

 

Linear Workflow Paths

Warranties moved through defined stages: Sale → Registration → Active → Claim → Resolution. Each stage had explicit ownership. No ambiguity about whose responsibility something was or what happened next. This is what killed the 17-day claims cycle — the delays were almost entirely handoff confusion, and linear paths with task assignments eliminated that.

​

Contextual Collaboration

Communication happened inside each warranty's record — not in a separate chat, not in email. When a claims processor needed clarification, they asked right there. Anyone joining the claim later saw the full history. This is the same pattern I'd built for the Dais Platform for insurance submissions, adapted for warranty workflows. It worked there for the same reason it worked here: context is what gets lost, and lost context is what creates delays.

​

One Interface Per Role, One Data Model

Shop owners got a stripped-down, fast interface optimized for register use. Insurance teams got full claim visibility with history and audit trails. Purchasers got a simple self-service experience. All three ran off the same underlying data. No duplication, no sync issues, clean reporting by default.

​

Automate the Reporting

23 hours a week was being spent generating reports from data that already existed. The new system generated those reports automatically. That number went to zero.

​

Ship on Time by Focusing on What Mattered

We had three months. We could have built a lot more. Instead we focused on the workflows that would actually replace spreadsheets and drive adoption — then iterated from there. POS integration started with form input (fast to build) and added API integration for the most popular system in a later release. The principle: ship the core value, don't let perfect be the enemy of launched.

​

Outcomes

• 91% faster claims processing (17 days → 1.5 days)

• 83% reduction in support calls

• 23 hrs saved weekly on manual reporting

• Launched before Christmas — on deadline, as required

• Replaced a failed internal system and actually drove adoption

​

Lessons Learned

The delays weren't where anyone thought they were.

The 17-day claims cycle sounded like a capacity problem. It was actually a context problem. Once you keep communication and history inside each claim, the delays mostly disappear on their own. Diagnosis first, then design.

​

Adoption is a design problem, not a training problem.

The previous system failed because users had to learn it. A system that shows you exactly what needs doing doesn't require onboarding — it just works from day one. The task-based model was the difference between the system that failed and the one that got purchased.

​

Speed at the point of sale is non-negotiable.

Shop owners have customers waiting. If warranty registration takes longer than pulling out a paper form, they'll use the paper form. The interface had to be faster than the alternative, or it wasn't an interface worth building.

​

​

​