How a design sprint solved the $30k patient cancellation problem
During my time in New York, I worked at Web.com on a product called Lighthouse360. Their mission is to create an easy-to-use patient communication system that helps dental practices grow and succeed. The means of accomplishing this mission can be summarized in one word — automation.
The Problem with Patient Cancellations
Any appointment or reservation-based business knows that this can be an issue that impacts their bottom line.
Imagine you own a new popular restaurant and it’s fully booked for the next month. However, each day you have 10 cancellations or no-shows. Now, you would have lost some money on those cancelled reservations, but fortunately you can fill those tables with walk-ins.
If, however, you owned a dental practice, chances are you are not going to have patients walk in without an appointment very often. When was the last time you just walked in without an appointment and was able to get your teeth cleaned? Each cancellation means an empty seat, which equates to lost revenue — $30k/yr to be more precise.
Design Sprinting
Our team saw this as an opportunity to really meet a deep customer need that has never been addressed by technology. We ran a design sprint to build a feature that detects and fills upcoming empty calendar slots, including last-minute cancellations.
The JTBD framework was used to define the problem.
As a Schedule Manager, when I have a short-term opening in my schedule, I want a way to put a confirmed appointment on my calendar in that slot, so that I can minimize openings in my calendar over the next 3 days.
We already had the problem, all we needed to do was define it in a job story format. “Schedule Manager” was the overarching role we decided on because sometimes the dentist, hygienist, or office manager made changes to the calendar. Our customers defined “short-term” to be 3 days, which gave us concrete requirement constraints.
Reflection #1 — We spent a significant amount of time prior to this exercise to make sure we were solving the right problem. A nationwide survey with thousands of responses and user interviews confirmed that addressing the patient cancellation problem should be our primary focus. Other issues, like assuring up-to-date patient information or getting payments on time, also came up as big problems that would be addressed in later sprints.
Map
We’ve built many relationships with dental practices, having been in the business for over 10 years. I spoke to dentists, hygienists, and office managers that would share with me how they handled same-day patient cancellations. Some of the workarounds included mass emails to their entire patient base or calling patients from a shortlist of those who said they would like to come in sooner if possible. Most of the time, they were not able to find someone to come in because they could realistically only call a handful of patients before they have to go back to their other tasks for the day.
Reflection #2 — Our group was very familiar with the workflow of the schedule manager because we’ve had many customer conversations about this exact problem. This made the exercise run very smoothly with active participation from the entire group.
Sketch
Everyone is a designer, whether you have the title or not. The value of this exercise was to generate as many ideas as possible and it’s important to make clear at the beginning that there are no bad ideas. An engineer’s brain works differently than that of a designer or product manager. There was a diversity of solutions that I would’ve never thought of before.
For example, a developer sketched the idea of a chatbot asking the Schedule Manager for the date, time, and length of an appointment they wanted to fill. The bot would then present him/her with several patients lists to choose from. The Schedule Manager would ask the bot to send a mass message to those patients and the wait for an appointment confirmation to come in.
Reflection #3 —Strive for 10X solutions. The most important part of this exercise is to take risks. There will be plenty of opportunity to worry about constraints later.
Decide
The PM was the decision maker, but it was really a group decision. We concluded the solution needed to do two things well. 1) detect open calendar slots 2) fill them with appointments.
Here’s how it works — once an open calendar slot is detected, we show a notification modal asking the Schedule Manager if they would actually like to fill that slot. If yes, a mass text would be sent to patients, who have not had a teeth cleaning in over 6 months. When a patient texts back with “Y”, we then notify the dental office via another notification modal.
Other concepts, like the example in the Sketch section, were great ideas, but provided excessive work for the Schedule Manager. Instead of asking them which slots they wanted to fill, why don’t we detect the openings using our technology and find patients automatically for them? We wanted a solution that was more automated so it would seem like magic once it worked.
Reflection #4 —Even though a decision was made, we still had questions. Were we risky enough? Was the concept simple to understand? How feasible are we able to prototype and test the concept within the next 2 days?
Prototype
I created the prototype using Framer and the engineers hacked together a backend texting solution with Twilio. With limited time, we didn’t have the luxury to worry about making something perfect, nor real. As long as we were able to get patients into empty chairs, it didn’t matter if the user interaction was made up of smoke and mirrors.
Reflection #5 — Super stressful having to create a code-based prototype in half a day. I wanted to mirror the actions users would take on the actual web app, despite being told it doesn’t need to be perfect.
Test
Everyone’s favorite part of the week. All those hours being stuck in a room together with sticky notes covering the walls is somehow all worth it.
Goal
For 2 offices, fill at least 1 empty calendar slot each
Procedure
- Schedule Manager (SM) notices an empty calendar slot for a teeth cleaning within the next 3 days
- On the prototype’s UI, the SM selects that empty calendar slot they want filled and triggers the “feature” to find a patient
- Every 10 minutes, send a text message to 30 different patients from the “Due for Teeth Cleaning” list
Results
- Office A— empty slot filled after 1.5 hours, 270 texts to patients, 1 patient unsubscribed from office texts
- Office B— empty slot filled after 50 minutes, 150 texts to patients, 1 patient unsubscribed from office texts
Post Sprint
Coming off the high of our successful design sprint, we needed to realistically think about how we could build this feature at scale. We had 2 pressing questions.
How do we know which calendar slots should actually be filled? It could be the hygienist’s lunch hour!
The feature would only trigger when an appointment is cancelled vs all empty calendar slots. This way, we would know for certain that it is truly an open appointment slot and the dentist/hygienist is free to see a patient.
How do we avoid running out of people to contact?
This was a little more difficult to solve because there is a finite list of patients for each dental office. It was decided to decrease the number of patients we contacted per time frame so we wouldn’t run through the list so quickly.
We also focused on levers that would address the running out of people to contact issue. These things included improving our text messaging and selecting which patients were more likely to say yes and contacting them first. For example, those that didn’t come in for more than 1 year, but less than 2 years, were more likely to respond (our customers gave us this insight and we saw it to be true from our data as well).
We call this patented solution “Fill-In” and it was released to all customers on June 2017.
