In-development
COMPANY
MY ROLE
TEAM
THE CHALLENGE
When the system says no, what happens next?
The problem
The system couldn't tell the difference between a bad risk and a complex one
Our quoting flow was binary by design: you qualify, or you're rejected. Think of it like airport security with no secondary screening, anyone who triggered a flag was simply turned away. Customers with high-value homes or older properties were hitting automated dead ends, not because they were bad risks, but because the system had no way to look closer.
The downstream impact was high-value customers walked away with no alternative, support teams absorbed calls they had no process to handle, and we captured none of the data on why these customers were leaving.
THE SOLUTION
A layer between the customer and a dead end
The exception handling framework sits inside the existing quote flow, invisible to customers who qualify normally, and activated only when a property falls outside standard parameters.
Rather than a hard rejection, the system now evaluates, routes, and either resolves automatically or hands off to a specialist with the right context to close the deal.
Click on the "year built" field to try out the prototype
My process
Where we still say no- not every edge case should be saved
The framework includes hard stops, conditions that result in an automatic rejection regardless of which path a customer is on. Making these explicit was as important as designing the exception paths themselves. It gave the business clear boundaries and protected evaluation layer.
01
Heritage status
02
Outdated wiring
03
Plumbing risk
04
Aged roof
05
Financials
KEY DECISIONS
Where design thinking shaped the solution
Built for scale, not just Phase 1
I solutioned using reusable components in the rules engine so that future exception triggers (others still being defined) could be plugged in without a core redesign. Phase 1 covers home value and building age with the framework was built to absorb what comes next.
Progressive disclosure was a considered concept, but because we are building with other phases in mind, having additional fields trigger would be overwhelming and prolong the customers' quote journey.
Only ask hard questions when they matter
The product and underwriting team's instinct was to surface detailed property questions: wiring type, plumbing materials, roof age early in the flow and filter aggressively. My concern was that this would create friction for customers who would have qualified anyway, and signal distrust early on.
The resolution:
Questions only trigger when a customer has already entered an exception-eligible segment. Everyone else moves through untouched. Less friction earlier, better data quality overall. Deciding the trigger point in the journey was the most difficult part.
Validate in the background, not in the customer's face
Rather than asking customers to self-report their home's rebuild cost (which introduces inaccuracy and feels interrogative), a third-party data source validates property details silently behind the scenes. The customer never feels scrutinized, and the system still gets the signal it needs.
THE FRAMEWORK
Keeping the existing two paths
The exception framework routes customers one of two ways. Standard approval for customers who qualify, and an automated exception path for customers who trigger a flag and can be resolved digitally.
Standard approval
Automated exception
The path decided against
A third path- specialist review was on the table. The idea was customers who don't auto-resolve get routed to a callback queue where an agent evaluates and closes the policy manually.
This was decided against it for Phase 1 for two reasons:
Why not show price estimate to hold engagement?
Automated exception
Phase 2 revisits this. Once the automated path has built enough of a data layer to define what a high-value referral looks like, specialist review becomes a targeted tool rather than a catch-all.
