The catalog nobody had fixed
Role: Senior Analyst, BizOps Scope: 2-Wheeler and 4-Wheeler Insurance Catalog Team: 20-person onsite operations team, plus cross-functional stakeholders across Product, Category, Engineering, and CX Outcome: 9% reduction in catalog errors, improved premium accuracy, measurable drop in endorsement-related CX tickets
The problem no one had structurally solved
My first week at PhonePe, I was handed a problem that had been sitting unresolved for months.
Users were dropping off PhonePe's motor insurance search page. The surface reason was known: the nomenclature was a mess. Users searched for their vehicle, thought they found it, and often hadn't.
The response until then was reactive. One-off corrections when something escalated enough to demand attention. Nobody had looked for the root source.
I was given the mandate to fix it properly. The deeper I went into the data, the clearer it became: this was not a search problem. It was a data trust problem sitting at the foundation of the insurance purchase experience.
Automobile nomenclature in India is inconsistent in ways you don't notice until you're inside the data. The same car, a Maruti Swift VXi 1.2, appears as five different entries across five insurance partners. The same OEM shows up as Mahindra, Mahindra and Mahindra, M&M, and variants beyond those. For motor insurance, where a vehicle's exact cubic capacity determines the premium, this creates real financial risk.
A customer who selects a 1098cc variant when they own a 998cc vehicle is buying the wrong policy. Most customers remember the model name, maybe the variant. The cc slab is invisible to them. The consequences are not. Wrong vehicle mapping produces wrong premium calculation, and if a claim gets raised, it triggers endorsement — one of the worst post-purchase experiences in insurance.
That was the real problem. Not drop-off. Data trust.
Why this had never been solved before
PhonePe had never done a catalog revamp at this scale. The data came from multiple insurance partners, each with their own naming conventions, their own catalog masters, their own definitions of what a "variant" is. No single source of truth existed.
Two technical approaches were explored before I ruled them out.
Fuzzy logic matching maps similar-sounding names to a canonical form. In theory, clean. In practice, it broke on edge cases constantly. CNG variants, limited-edition models, regional naming differences. The algorithm could not reliably distinguish between a genuine alternate name and a genuinely different vehicle.
ML-based catalog generation would train a model to infer correct vehicle details from partial data. This performed worse. The model generated variants with no real-world equivalent — vehicles with no way to buy, insure, or validate. In a regulated industry where every policy has legal standing, a fabricated vehicle in your catalog is a liability, not a minor bug.
I ruled out both approaches. Not reluctantly. The technology was not ready for this problem, and forcing it would have created failure modes we had no way to control.
The framework: Coverage, Accuracy, Hygiene
I broke the problem into three dimensions.
Coverage: Are all valid vehicles, variants, and OEMs present in the catalog? A user who does not find their vehicle is an immediate drop-off.
Accuracy: Is each vehicle mapped to the correct attributes — cc, fuel type, body type, seating? An inaccurate mapping leads to wrong premiums and endorsements downstream.
Hygiene: Is the catalog free of duplicates, ghost entries, and naming inconsistencies? Poor data hygiene degrades both coverage and accuracy over time.
Every decision, from how we sourced data to how we validated entries, was evaluated against all three. If a fix improved accuracy but reduced coverage, we went back.
What we actually did
The core work was unglamorous and methodical.
I consolidated the catalog masters of all insurance partners — every vehicle entry, every variant, every OEM name — into a single working dataset. Then we cleaned, deduplicated, and standardized it.
Every entry was validated against at least three independent checks before it entered the master catalog. No invented vehicles. No inherited errors. No variants present in one partner's system but nowhere in the real world.
I led 20 onsite operations specialists through this. My job was to give them clear criteria for what a valid entry looks like, defined escalation paths for edge cases, and a daily feedback loop to catch systemic issues before they compounded. This had never been done at PhonePe at this scale. We were doing it while the live product kept serving customers.
The hardest part: cross-functional alignment
The catalog touches each team differently. For Category, it's a negotiation surface with insurance partners. For Engineering, it's a database architecture question. For Operations, it's a validation workflow. For Product, it connects all three to the user experience.
Getting everyone to a shared understanding of the problem, and a shared definition of success, was the most difficult part of this project.
Every assumption I brought to alignment meetings got pressure-tested. Every framework I proposed got scrutinized. The scrutiny made the approach stronger. Questions I couldn't answer in a meeting were questions that would have broken execution.
By rollout, the cross-functional alignment was not just documented. It was internalized.
Measuring what mattered
I ran A/B testing to measure how new customers responded to the revamped catalog, tracking search-to-selection conversion and drop-off rates.
I also coordinated with the CX team to track endorsement-related tickets — issues raised by customers mapped to the wrong vehicle or wrong premium slab. This was the downstream metric that most directly reflected whether we had solved the actual problem, not the surface symptom.
Results:
- 9% reduction in catalog errors across 2W and 4W categories
- Measurable improvement in premium accuracy from correct vehicle-to-cc mapping
- Decline in endorsement-related CX issues post-rollout
What I'd do differently
I'd have started with a category-level error heatmap, breaking down where errors were concentrated before cleaning anything. Mid-segment 2W vehicles likely had disproportionately high error rates given the number of variants in that segment. A clearer view of error distribution upfront would have helped prioritize faster and give stakeholders earlier proof points.
I'd also have pushed for a partner data SLA earlier in the process — a formal standard for how insurance partners must submit vehicle data to PhonePe going forward. We cleaned the existing catalog. The long-term protection is preventing the same problem from re-entering through new partner onboarding.
Users who purchased through the revamped catalog never knew it had been rebuilt. They found their vehicle, got the right premium, and didn't file an endorsement. That outcome is what a successful infrastructure fix looks like.
This project was completed during my tenure as a Senior Process Analyst at PhonePe Insurance. All metrics are directional and have been shared with appropriate discretion.