In-App Support
Problem:
We have a high customer support call/email volume compared to the industry standard. This means our users have longer wait times and our support costs will be unsustainable as we scale up. After going through the emails and call logs, we've discovered that there are many questions coming in that are repeated simple to answer questions. We believe that up to 60% of our support calls/emails can be answered by an in-app FAQ or self-service functionality within the app.
Hypothesis:
If we re-route customers inquiries to the right section of the app, customer service tickets/$ spent will go down. If we answer repeatable questions in the app, customer service tickets/$ will go down.
Solution:
We want to build a tool in the app, that not only answers questions with educational content but re-routes users to the right section of the app so they can be enabled to fix their own problems. Allowing our customer support to tackle more complex issues and reducing their repetitive tasks. This creates a better experience for the user since answers to their questions are easily found and when they do need to contact support their wait time will be less.
Before beginning this the Root Insurance app did not have a customer support section. We only had a button that would auto fill our customer support email into your mobile email app.
The Process:
We brainstormed as a design team and came up with multiple solutions for what we believed the best in-app support looked like. Concepts revolved around chat-bots, searchable content, and different ways to get through FAQ navigation.
I then narrowed down the ideas into 3 versions which was pitched to the product team. We picked a route and narrowed down to what our MVP version would look like with concepts for where we could go next.
Design was in charge of figuring out topics to show based off tickets Customer Support received.
At this point, we started our content system (a glorified excel spreadsheet). I dug through our customer support tickets searching our top themes for repeated topics and questions. We created a navigation that reflected our customer service ticket volume and started sorting that volume based on where the user was in the funnel.
We decided our content should be dynamic and adjust based on where you were in the funnel and annotated for engineering when to show what question. Since our FAQ could host not only static educational content, but also re-route you to different areas of our app, we needed to annotate the content for engineering to let them know where each question would take the user, and when to show a text-only response.
After all of this, we honed our UI for the tool itself and focused on where we wanted to start and give ourselves room to grow in the future.
Results:
We saw a 44% decrease in support tickets in our upfront user flow (we call it the "Test Drive") compared to control, and we saw a 10% decrease in tickets for our Root Insurance Policyholders compared to control. Overall we'd call this a successful project, we've helped reduce support costs, and we believe we can iterate on our ideas further to continue to see this cost go down. We have high engagement on the user side with the feature, and we're watching out for where we can make it easier for them to find what they need.
With this feature we can also easily track where users are going for support help, which can help us gain insight to areas of our app that need a better experience overall.
Future Thoughts:
Before launch we gave thought to where we wanted the project to go next. Our next logical step would be to introduce search. We could then surface poplar searches and create a faster experience to getting the help you need. This experience was not implemented while I was on the Policyholder Experience team, but was used as reference for the future projects on this section.
Background:
The In-App Support project was launched the Summer of 2018, while working at Root Insurance.
Our team was made of: a Product Designer (Myself), a Product Manager, a Copywriter, a Tech Lead, and a team of ~6 engineers.
