Px System

The Context

What Does It Do?

PX is an internal platform built to guide producers, insurance agents, through the sales process. Its first and most critical step: lead qualification.

Producers received leads from multiple sources:

• The self-service quote form
• Inbound calls
• Cold calls.

Leads coming through the quote form arrived already qualified and quoted, producers only needed to close. But for inbound and cold calls, the dynamic was different. And that's where the bottleneck lived.

The Problem

Why It Matters

When working inbound or cold calls, producers had two options:

1. Share a quote form link
2. Quote the lead directly.

Most preferred to quote directly, since keeping the lead on the phone increased engagement and improved conversion rates.

But quoting directly required completing a long form, and eligibility was only confirmed after submission. Once submitted, the request would go to the quoting team, with response times of up to 60 minutes.

This meant producers were investing time upfront without knowing if the lead was even eligible. In practice, time was being spent before value was guaranteed.

This raised a key question:

The user

Who It Impacted

To understand how producers actually worked, I traveled to North Carolina with the PM for an on-site research sprint, shadowing calls, interviewing producers, and mapping their tools and workflows.

1. On-site sprint in North Carolina / 2. User journey based on shadowing and interviews

• Performance-driven
• Time = revenue
• Momentum-sensitive
• Prefers direct engagement

"For a producer, every minute spent on a non-qualified lead is a minute not spent closing a deal."

- Daniel, insurance expert.

When on a call, momentum matters. Sending a link breaks the flow. Quoting directly keeps the lead engaged. Producers chose the longer path because sharing a link with a lead that is actively shopping around felt like losing them entirely.

Any solution would have to fit inside the rhythm of a live call. Fast enough to run with a lead on the line. Simple enough not to disrupt the conversation.

Diagnosis

What We Know

The on-site research made the root cause clear

Qualification was happening at the wrong stage. Producers were wasting time with non-qualified leads

The on-site research gave us the raw material. I translated the findings into a storyboard that was used to align leadership on the problem before any solution was proposed.

With the problem diagnosed and leadership aligned, the direction was clear.

Solution

How We Solved It

The core question:

What's the minimum information needed to confirm eligibility, fast enough to work during a live call?

I worked with engineering to understand what was technically feasible during a live call. The 7-input model came out of that collaboration, the minimum data needed to run an eligibility check using DOT infrastructure already integrated in the platform.

Result

What is the impact?

Launched in 2024. The impact was immediate and measurable.

Beyond the time metrics, the change had downstream effects: the number of proposals submitted per week increased, and so did closed sales. Producers responded positively. Direct feedback confirmed they trusted the new flow and preferred it over the previous process.

My Role

What Was I Responsible For?

My role was to lead the design end-to-end, from understanding the problem in the field to shipping the final flow. I collaborated with engineering on feasibility and owned the UX and UI of the final qualification flow. The PM and I made product decisions together. Engineering validated technical viability. Leadership approved the direction. Design, research, synthesis, framing, and interaction were all mine to drive.

Conclusion

The Takeaway

This project reinforced something I keep coming back to: the most valuable design decisions aren't always about the interface. Here, the real work was diagnostic, identifying that the problem wasn't the form, it was the sequence. Fixing the flow only mattered because we first understood why producers behaved the way they did. That's the part that doesn't show up in screenshots.

What I'd do differently?

I would invest more time testing edge cases before launch, specifically scenarios where eligibility status could return incorrect results. At scale, even rare errors created friction for producers and eroded trust in the tool. Earlier stress testing would have reduced post-launch fixes and accelerated adoption.