From Client Feedback to Scalable Solution

The feedback came directly from a broker client:

"If we search on our system by name, postcode, registration, email address, if the customer has applied multiple times, it can be incredibly arduous to find their policy. Many customers don't remember references or policy numbers so this can result in us checking 20+ records to find the actual policy. This is made worse due to aggregator quotations."

‍

Twenty records. That was the daily reality for brokers trying to help customers on the phone.
The Product Owner's initial suggestion was a checkbox to filter live policies from inactive ones. It seemed reasonable. But when I started investigating, I discovered the problem ran deeper than filtering. Client duplication from online aggregators meant the same person appeared multiple times in the system. The search was querying 11 parameters simultaneously, causing performance issues. And different brokers had entirely different mental models for how they thought about policy status.
A checkbox would have been a plaster on a wound that needed stitches. This project taught me to look past the initial suggestion to understand the underlying problem.

Phase 1: Finding the Right Solution

When this client feedback came in, the PO had a simple solution in mind a checkbox will cut it. I started by understanding why brokers wanted it. The real need was clear: distinguish live policies from everything else, quickly, while a customer was on the phone.

But a single checkbox assumed a binary world: live or not live. Reality was messier. Brokers also cared about prospects they were actively working, policies that were about to renew, and clients who had lapsed but might return. A checkbox would solve one problem while ignoring others.

Exploring the Options

I discussed technical constraints with engineers and learned the system architecture. Then I explored three approaches:

• Client status filtering would categorise people as potential, current, or past clients. Intuitive for users, but it required data model changes that were not feasible in our timeline.
• Policy status grouping would use semantic labels like "Live Policy" that matched how brokers thought. When I validated this with a broker, he loved the concept. But engineering raised concerns about UI responsiveness when clients had high policy volumes.
• Multi-dimensional filtering would let brokers filter by multiple criteria. More flexible, technically feasible, and scalable to future needs.

I chose the third option, but incorporated the broker's feedback: I used multi-select dropdowns with semantic groupings for policy statuses, balancing his mental model with technical constraints.

Prioritising for Impact

I had proposed 8 filters. Given tight timelines, I worked with the Product Owner to prioritise. We selected three:

• Policy Status addressed the core problem directly. Brokers could filter to show only live policies with one click.
• Brand helped brokers working across multiple brands separate clients with common names.
• Line of Business enabled contextual filtering. When a customer calls about their pet insurance, the broker can filter to show only pet policies.

Three filters instead of eight. Enough to solve the problem, focused enough to ship quickly

Phase 2: When Search Itself Breaks

A year after Phase 1 shipped, new problems surfaced. A broker reported that searching for French surnames like "Le Page" caused the system to time out. Another found that short business names like "L&D LTC" returned over 500 records.

I investigated with engineering and found the root cause: the search queried 11 parameters simultaneously. When a broker typed "Le", the system searched first name, last name, business name, postcode, phone number, and six other fields all at once. For common letter combinations, this created massive result sets and API delays.

‍

The Proposed Solution

I designed an advanced search feature that would let brokers specify which parameter to search. Instead of searching everything for "Le Page", they could search "last name only". This would reduce search time by up to 11 times for problematic queries.

I also proposed capping results at 500 with a prompt to refine search criteria, preventing the system from attempting to load overwhelming result sets.

Where It Stands

I documented my findings and asked the Product Manager for data on how frequently these issues occurred, effort estimates, and value justification. The work stalled at discovery as competing priorities took precedence.

This was frustrating, but it taught me something important: edge cases need quantified impact to compete for resources. Without data on frequency and business cost, it is difficult to justify investment over other priorities.

The Outcomes

Phase 1: Complaints Stopped

After the three filters shipped, complaints about the search stopped. The Policy Status filter eliminated the need to manually open 20 or more records. Brokers could find live policies immediately.

The real validation came post-launch: brokers requested the same filter be added to the client detail page. They had found it so useful in search that they wanted it everywhere. Good solutions spread.

Phase 2: A Pattern Recognised

While the advanced search feature has not shipped, the investigation was valuable. I now understand the search architecture deeply, and I have a ready solution when the business case becomes clear.

‍

What I Learned

Look past the requested solution. The checkbox request would have shipped faster, but it would not have solved the problem. Taking time to understand the underlying need led to a more scalable solution.

Validate with real users, then compromise wisely. The broker I tested with wanted semantic groupings. Engineering had concerns about performance. Multi-select with semantic labels gave both sides what they needed.

Edge cases need quantified impact. Phase 2 taught me that good solutions are not enough. To compete for resources, problems need data: frequency, cost, business impact. In hindsight, I should have pushed for usage data earlier.

Ship what solves the problem, not everything possible. Eight filters would have been comprehensive. Three filters shipped faster and solved the core need. The others can come later if needed.