Clearcover Agent Quoting
Tools Used: Figma, Mural, Jira, UserTesting
Client: Clearcover
Research Methods: Surveys, Moderated Interviews, Usability Testing, and Concept Testing
Role: Senior Product Designer
Some Context on the Agent Quoting UI (AQUI)
AQUI was designed to support internal (worked for Clearcover) and external (independent or brokerage insurance agencies) insurance agents while they quoted their customers a Clearcover auto insurance policy.
The agent could either “start from scratch” and quote a customer a single Clearcover quote, or an agent could “bridge” into AQUI by starting with a comparative rater site that would use a customer’s basic information to display multiple insurance carriers' quoted prices. If Clearcover was desirable, an agent could bridge into our UI to finish the quote and purchase an insurance policy.
My Role & Process
I worked as an embedded Senior Product Designer on the AQUI team, working closely with the Engineers and Product Manager. I attended the weekly ceremonies, including daily stand-ups, sprint planning, sprint reviews, and retros. My Product Manager and I had weekly design review meetings to stay aligned on user and business needs.
AQUI was extremely important for the company's success, as much of our business came through the agent channel vs. the self-service channel.
I supported the product for about two years and built new features while maintaining and improving existing functionality within the experience.
To stay informed on our users' needs, I attended monthly shadowing calls to observe our agents’ screens while they took calls and chatted with customers. I could ask about how the software was working or not working and dig into specific features with our users, which helped me and my product team understand what problems users were facing so we could take action.
Running Reports: A Common Agent Frustration
Through my regular monthly shadowing sessions with agents, one problem in particular kept presenting itself. I heard it shadowing session after shadowing session:
As an auto insurance agent quoting clearcover, my Customers abandon the quote after reports run because the price jumps.
It's annoying because reports aren't run until all the customer's information has been collected and they are about to purchase. It’s a waste of time, and I risk losing that customer altogether because they lose trust in the quoting process.
When I started to think about solving this problem, there were two flows an agent could take:
Start from Scratch:
Collect all driver(s) information
Collect all vehicle(s) information
Select the customer’s quoted coverages
Review a summary of the quoted policy
Run driver and vehicle reports
Purchase
Bridge from a Comparative Rater:
Collect all Driver, Vehicle, and coverage information in comparative rater site
View multiple insurance carriers’ quoted price
Continue with Clearcover & bridge into our UI, viewing the summary page
Run driver and vehicle reports
Purchase
Starting Designs
No matter the flow, “Start from Scratch” or “Bridge,” agent’s went from Summary to Reports to Purchase.
What’s the deal with reports?
The reports we ran included a credit report, verification of a customer’s current carrier, a claims history report, and a motor vehicle record.
Reports were run at the end of the quoting process because each report cost money. The price ranged from a few dollars to about $40, some of which would be billed back to the agent to cover. We needed enough information about the customer to run the reports against.
Additionally, if any information was updated or changed on the customer’s application/quote, some reports would potentially need to be re-run, and the agent would be re-charged for running that report.
So I wondered,
How might we allow agents to run reports in “just right” timing, not too early or too late?
Through rounds of iteration, usability testing, and design reviews with my team members, product leaders, and other designers, I landed on a set of designs that made running reports available to agents at the earliest possible step: Coverages.
At this point, we had enough information about the customer to run the reports, and the likelihood of edits to Drivers or Vehicles would be minimal.
The design removed the Reports page from the stepped navigation but made running reports an option for users on the Summary page. This way, as an agent reviewed the quote with their customer, they could run the reports to have a truly accurate summary to discuss with their customer before landing on the Purchase page.
Additional Learnings
Through user testing, I also learned that agents needed a more detailed price breakdown as they worked on the quote. This was because customers often had questions about why they were being quoted a specific price and what went into that price.
So, I kept our footer price display for easy viewing page to page but added a detailed price breakdown card in the Reports drawer for the Monthly or Pay in Full options. I used the same layout agents were familiar with and understood from our Purchase page.
Updated Design
In the end, this design gave the agents the freedom and accuracy they needed to effectively to their jobs.