Driving 35% YoY: Just with a simple twitch
The wrong fix we almost shipped
Once we relaunched the entire car insurance quotation experience mobile first, something new showed up in the metrics: a huge share of users were dropping off right at the landing page. The obvious move was to redesign the landing page and add more trust signals. But before touching a single pixel, we dug deeper into the funnel and found the real pattern. Most of that drop off was not about the landing page at all. It was happening because users typed their car's brand or model and our search could not find it. "Hyundai" typed as "Hiundai" returned nothing. One typo, and the sale was gone before it ever started.
The fallback for a failed search was a wizard: collect the user's info and have an agent call them with a quote later. It felt like a safety net. It was actually a leak, because most of those users never answered the call. The team's first instinct was to fix this with a better CX follow up strategy: improve callback timing, improve the email copy, chase the leads harder. It is a completely reasonable idea, and exactly the kind of patch that quietly turns into its own project, its own backlog, its own team, while the real problem stays untouched underneath it. So we stopped and asked a simpler question: what is actually broken here? Not "how do we get people to pick up the phone." The problem was that users could not find their own car.
The real fix: Teach the search to understand typos, not the user to spell better with AI
If someone had walked into an insurance office in 1995 and said "I have a Hiundai," the agent would have understood instantly and fixed it without even mentioning it. The system needed to do what the human always did.
The first idea on the table was to throw AI at every search query, having a model read each user's input in real time and figure out what car they meant, on the spot, every single time someone searched. We considered it, and turned it down for this specific problem. Not because AI cannot do it, but because it was the wrong tool for a problem we already understood: we already knew the most common misspellings our users made. So instead of processing every input through a live model, we built a fuzzy search engine tagged against the real, recurring typos we had already seen in the data, using AI as a development accelerator to help spot and tag those patterns faster, not as the live decision maker at checkout.
A simple search bar. No live inference. Just real, recurring "wrong" spellings mapped to the right answer.
From "No" to "Found It" in one sprint
Search efficiency sat at 56.5%. We were only finding about 5 out of every 10 cars people actually owned.
Search efficiency got to 97.4%. Nearly 10 out of 10. An estimated +$21,140 in annual premiums that had been silently lost to a search bar that could not spell.
Once the search stopped rejecting real customers, total sales grew 35.2% year over year, adding more than 400 additional policies sold per month compared to the year before. Today, when a user's car is not found, it is because of a clear business rule, like pickup trucks or motorcycles that this insurer does not underwrite online, not because the tool failed them. That naturally opens the next question: how do we turn those vehicles into a sale too? That is not solved yet, but that is what is coming next.
The takeaway
The biggest lesson here was not technical. It was about where to look. The team's first instinct was to treat the symptom, low callback rates, as its own new project. The real fix was one level up: stop losing the user in the first place.
Design's job was not to make checkout prettier. It was to notice that "we need better CX follow up" was really code for "our search bar is broken," and to have the discipline to zoom out before building the wrong solution.