Auto Billing
Know the cost before scheduling a delivery
Project Outline
Overview
One of the most common reasons we reach out to patients about refills is to confirm copay. Since the patient cannot see their copay when they schedule their refill, we either reach out after billing to notify them of the copay as a courtesy, or if the copay is above a certain threshold, we ask them to confirm the price before fulfillment.
Billing requires many steps and time to provide the best pricing option to patients. However, many of our billing rules are predictable, such as coupons and deal criteria. With this predictability, we are able to set clear parameters for auto-bill insurance or the appropriate rebates, coupons, vouchers, and deals to surface the cheapest option. We could then auto-bill as soon as a patient or patient care representative scheduled a delivery and reduce contact points necessary to get the prescription to the patient at the lowest price.
The Problems
-
Patients can't see pricing when they schedule a delivery which results in multiple contact points (poor patient experience and more work for our team)
-
Patient care spends a lot of time manually billing prescriptions and contacting patients to update them on their copay
Goals & Metrics
-
Reduce overall manual comms / shipment by X%
-
Automate X% of patient scheduled refills
-
Automate X% of patient care scheduled refills
* exact percentages are concealed for confidentiality
Our Hypotheses
-
Increasing auto-billing success and showing operations members what the bot did will decrease time spent triaging billing and reduce manual contacts
-
Increasing auto-billing success will allow us to display pricing to patients immediately before placing their order will reduce contacts
Initial Research
I kicked off this project by shadowing and interviewing our internal users. I then created a summary of the main UX problems with our current tool. I like to record my interviews and share highlights and lowlights with my team. Here’s an embarrassing screenshot of one of those interviews:
Flow Mapping & Sketching
Flow Map
After initial research, I’ll draw out work flows and work through some initial sketches to validate with my team.
Sketching
I’ll also work through sketches to validate with my team. I usually use pen and paper, but sometimes I use sketch freehand on my ipad. I generally pick 2 or 3 very different ux flows to discuss with my PM and Tech Lead.
Rough Prototyping & Iterating
After I validate some sketches, I’ll move into rough prototypes. In the first wireframes, we had a way to choose if you want to pay with or without insurance but after gathering feedback on the rough prototype, we realized people just want the cheapest option. So in the iterations that followed this one, we auto-selected the cheapest option.
Screen from one of the first rough prototypes:
Detailed Prototyping & Iterating
After I validate wireframes through critiques and usability tests, I moved into more detailed prototypes
Patient App - Native & Web
Since we couldn't auto-bill everything, feedback mostly pertained to copy around "why do some have prices and some don't?" and "when you can expect to know the price?"
Internal Tool
Since our internal users are power users, we show them more of what auto-billing is doing behind the scenes. We also added a widget to help us tune our auto-billing system.
New Component Details
Whenever I create new components, I produce detailed breakdowns for my engineers. I try to think of any questions they might ask me and answer them in these breakdowns. Here’s a screenshot of part of the breakdown for the new Payment Summary Cards for the internal tool:
Successful Results
-
Autobill X% of patient scheduled deliveries
-
Autobill X% of patient care scheduled deliveries
-
Reduced contacts per shipment by X%
* exact percentages are concealed for confidentiality