In order for physicians to submit electronic claims and collect money from insurance companies, they need to be “enrolled” with the insurance company. This process involves submitting a large amount of paperwork to each insurance company. Kareo provides a service where they do this on behalf of the physicians and is completed by the Enrollments team. Kareo also provides a dashboard within the app where customers can submit enrollment requests and view the status of their enrollment throughout the process.
I was approached by our VP of Customer Success regarding issues that were taking place with Kareo’s enrollments process. It had become one of our top call-drivers and surveys showed that customers were dissatisfied with the amount of time it was taking to get their physicians enrolled with insurance companies.
At the time I wasn’t too familiar with the details of the Enrollments Process. I always begin all my design process by working with the product manager to write down all our assumptions and questions. As I interviewed internal team members in the Enrollments team, I found that everyone knew their own part of the process but no one really understood the process end-to-end.
This called for a customer journey mapping session - this is a method I use to collaboratively engage my team and help build common understanding. So I put key stakeholders and the customer-facing employees from the Enrollments team in one room. First, I had everyone define the different type of customers we provided our services to. I had them chose 1 user to focus on for this particular journey mapping session. Once we did that, we defined the key stages of the customer’s interaction with Kareo’s enrollment process. On the left side, I listed out the kind of information I wanted to map out. This included:
Customers expected this whole process to take about a week. This process takes about a month and a large part of it is not in Kareo’s hands because we are waiting on the insurance companies. Customers would also assume that “Kareo will just do everything” when really it is a shared responsibility between Kareo and the customer to provide all the necessary paperwork.Ineficient Communication
When Kareo needs something from the customer, we typically email them asking them to provide specific information. A lot of times, customers wouldn’t check their email or claim that they never received it, which would delay the rest of the process.
When customers respond, instead of replying to the email they received, they will create a new email and send it to the enrollments team. This causes the link between the email and salesforce case to break causing further delay since this email will now go through a triage process.Lack of Transparency
Customers were unaware of what was going on once they submitted an enrollment request. As a result, they would submit duplicate requests and call support to find out what was happening.
Once my stakeholders were aligned on what problems we were trying to solve, I start putting together wireframes. Once I had these ideas together, I wanted to validate whether these concepts would successfully solve the problems we had identified. I contacted four customers with whom I had already established relationships with. These customers were a good representation of our different customer types. I walked through my concepts and had them think out loud. I received a lot of positive feedback - I found that people were excited about this, people wanted to know when this was getting released. This made me confident about moving forward with my designs.
Once I validated my concepts, I created high-fidelity mockups in Sketch and used Invision to create a prototype. I usability tested this prototype with 5 customers and 3 internal employees. Again the feedback was generally positive, there were a couple of usability issues that came up that I was able to resolve in my iterations.
I introduced two new features into the Enrollments Dashboard.Enrollment Tasks
The first is eliminating the use of email as a means of communication between the Enrollments team and the customer. We built a tasking feature within the app to replace the need for email. When the Enrollments Team would send an email to the customer from Salesforce, instead of sending this to their email, it would create a task for the customer and notify them of this task upon logging into the app. This way things aren’t getting lost in email and also gives a sense of responsibility to our customers- that they need to respond in order for Kareo to move forward in the process.
The second feature I’ve designed is the ability to track an enrollment in order to improve transparency into what Kareo is doing behind the scenes. The analogy I used here was a Shipping Tracker. This worked as a good analogy for us because it solved a very similar problem in that it seeked to reduce customer service calls by providing customers with full transparency on where there package is in the delivery process. Using this analogy, I chose to display an estimated completion date, which would help set proper customer expectations and reduce support calls. I also designed a timeline view for customers to quickly see the status of their enrollment. I used progressive disclosure for customers that wanted even more detail into what was being done with their enrollment request.
It was important to get buy-in from the internal enrollments team because their processes would be highly impacted by the new designs. Displaying an enrollment tracker to the customer would mean that they were now held accountable for these requests and had to be good about updating the statuses in the salesforce case.
This project was implemented by a remote engineering team in Costa Rica. This was a brand new team that did not have much experience with our product. We had to delay the launch by about a month due to challenges of being remote. If I could change one thing, I would have had more regular check-ins with the team. I have now implemented a process where engineers must add the designer and product manager to their pull requests for any UI changes. They typically will add in a link or screenshots that will enable us to see and test the new functionality. Once we approve these pull requests, the engineers can merge in their code. This has allowed both product and engineering to work much more closely together throughout the process.