Balancing speed and credibility in purchasing insurance at Coterie
SimplyBind
Coterie Insurance is an InsureTech company disrupting the small business insurance market. Using only a business name and address, the SimplyBind experience pulls additional information to evaluate an applicant against automated underwriting* rules. The core goal of SimplyBind is to provide ready-to-buy quotes in minutes rather than traditional processes which takes days.
*underwriting
the process of evaluating the risk of insuring a business by determining whether or not to insure them and how much to charge
At this stage in the project, the existing team had presented a live prototype MVP both internally and to a trusted user focus group in order to obtain feedback on our new concept.
the process
Testers were skeptical the process was too fast
It was that found internal stakeholders didn’t like how quotes were produced “too fast” and the system was not working as expected. As the new lead designer at this point in the project, I was tasked with validating this initial feedback and solving for these issues to get us to launch ready before losing buy in from our stakeholders.
Internal feedback from our key stakeholders indicated skepticism of user adoption.
Key screenshots from the state of designs at this point.
identifying the solution
In order to understand the initial skepticism, I needed to conduct user interviews to pinpoint the areas of friction.
I decided to interview 5 insurance agents with a range of industry experience. It was important to validate our internal feedback against what our actual end users would experience. Via contextual inquiry sessions, my goal was to find out what points in the flow might be negatively received and dig into the reasoning behind those negative reactions.
We ultimately gathered that insurance agents experienced friction and confusion in the following areas:
1) Inaccuracy and ambiguity when we used 3rd party data to validate and suggest business classifications. Agents felt uncomfortable with the pre-suggested classifications if they thought it could result in an audit or cancellation later.
“I wanted to know if there was something that I could have entered in the system that would have helped guide us to the correct classification”
2) Underwriting processes were not visible.
Agents complained they did not understand what was happening in the system. They wanted a greater sense of confidence in the pricing and eligibility of an insurance quote.
Agents felt checking eligibility should be more complete. They wanted to provide secondary operations or claims information so they could find out right away what might be declined for coverage
3) Inaccurate business details pre-filled into the system from our 3rd party data. However, this was overlooked as long as the information was easy to change.
Upon conducting these interviews, we learned that if we wanted to focus on speed, what agents need first is speed to determining coverage eligibility rather than speed to price. Interviewees expressed wanting to receive a quick “yes” or “no” accurately with better ways to validate or add business information. They also expressed skepticism in the lack of visible underwriting.
identifying the solution
How could we create an experience showing credible and accurate underwriting while maintaining time to task?
To address a lack of visibility to system status and processes, I identified areas in the existing design where we could detail out backstage processes without slowing down the user flow.
My goal was to increase satisfaction in the final quote by creating a sense of assurance that traditional underwriting processes were still happening in the background.
Solution #1: Explain how automated underwriting works
I improved the microcopy and utilized tooltips to provide transparency into the process and explain where prefilled data is sourced from.
I also used existing loading screens to provide progress descriptions. We used these opportunities to explain what automated underwriting endpoints are called that replicate a typical underwriter’s process to follow the usability heuristic of showing system status.
Solution #2: Provide reasoning when a business is declined for insurance coverage.
In conducting interviews, we found an interesting use case of or system where users constantly quote different applicants just to test what Coterie routinely accepts or denies for coverage.
We discovered this was the main goal when an insurance agent quotes any business. It is most important to first determine if an insurance company will quote a risk so that they do not waste additional time or effort with extra questions. Only after this initial step will agents start comparing quotes based on price.
I decided to make our declination screens a key part of the experience to build increased trust with repeat users who might return later. My solution included two major improvements.
Allow a user to receive a declination earlier in the process. After entering any industry that Coterie does not accept, I introduced an additional screen where the user would see the early declination. Rather than having adding additional information that would not affect eligibility, I refined the flow where something as binary as a “yes” or “no” on the industry of business could trigger that early declination.
Clarify underwriting reasons for the declination. We already had a library of rejection descriptions used for internal reporting. I leveraged these descriptions for the end user by mapping and exposing them to provide detailed underwriting reasoning for a rejection.
Solution #3: Emphasize what factors are used to evaluate a business and allow for users to adjust prefilled data for more accurate pricing.
After ensuring a business is eligible, I also simplified the process to make corrections on prefilled data. We had found that users did not mind correcting information if it was easy. In fact, interviewees viewed the corrections as necessary to obtain the most accurate price possible.
I also created concepts to allow users to verify business characteristics that affect our system’s pricing calculations. This addressed some concerns that we were not allowing users to disclose unique business characteristics for more accurate underwriting and pricing consideration.
the results
Delivering a fast and credible insurance quoting experience
After a few cycles of iteration and feedback with stakeholders on these design improvements, Coterie fully launched the new SimplyBind experience in July 2022.
Within a month, we saw the following results:
In the long term, we measured ultimate success by looking at two metrics. Total eligible quotes and total written premium increases over time would tell us if the new experience was being adopted and contributing to overall growth.
Success Metric #1: Total Quotes
Over the next year, we saw a steady increase in total eligible quotes doe to both an increase in usage and overall better risk selection* via the implemented automated underwriting.
Total number of quotes prior to SimplyBind launch (pink) vs total number of monthly quotes after SimplyBind launch (blue)
*risk selection
With automated underwriting, Coterie increased efficiency in declining coverage to ineligible businesses in order to build a book of business with less risk of claims. Additionally this process allows users to more quickly learn what kinds of businesses to quote with Coterie and can encourage users to create more quotes with businesses they know are eligible.
Success Metric #2: Total Written Premium
Contributing to our overall revenue, the steady increase in total written premium was due to selling policies with bigger premiums on average (for example, handling more complex or larger businesses) and increased usage of our new experience.
Report tracking weekly total premium from July 2022 to July 2023
what I learned
Make an effort to validate solutions
Though it felt strange advocating for user research in the midst of engineering delivery, I felt it would be valuable to confirm that we that we were solving the correct problem. I learned how insightful and quick it can be to validate feedback before continuing to iterate (the team was on design iteration #7 by the time I joined!). Luckily, I had an amazing team and two very trusting primary stakeholders in our VP of Insurance and VP of data who were willing to allow me the time to problem solve.
By spending a bit of extra time with our users, we saved time in future iterations and we uncovered core goals and motivators that have guided us in other design decisions we have made throughout our platform.