2. Phone Verification
Securing existing accounts and slowing the creation of duplicates.
PROBLEM SPACE
With any growing product, there will be areas that were either overlooked or deprioritized since a product’s initial launch — phone verification was one of these areas for SimpleHealth.
With over 90% of SimpleHealth’s traffic coming from mobile, phone numbers were an essential part of providing a largely text-based service following the initial consultation. Not only would patients be able to communicate with our PX (Patient Experience / Customer Support) team, they would get updates from their care team as a whole, like their doctors and pharmacists through text. Most refills were also conducted through a texted magic link.
Over two years into this venture, the business began to see returning users without an active subscription, marked by the reuse of their phone number. Of course, there were edge cases — incorrectly inputted numbers, changed phone numbers, etc. — all of which were resolved by humans in our PX team. The PX team was also responsible for merging duplicate accounts from the same individual. Due to this, we needed to be a better way for us to prevent or stop the flow of duplicate accounts, as to lower the load on our PX team. This reflected one of our focuses as the compliance team — creating automations or frameworks to better streamline the type of work that our PX team would have to service for patients.
OUR APPROACH
above: Verification component within intake, mobile integration with SMS
Reducing duplicate phone numbers meant that we had to create a multi-pronged approach to break down the issue. We had decided to only allow verification of phone numbers ONCE, but also collaborate with our PX team to merge existing accounts. With verification in place, the only time merging or phone issues should occur would be if a patient relinquished their phone number and the following owner also signed up for SimpleHealth (as it happens more often with families).
We had to reconcile with the fact that there would have to be some user friction if we were deny a phone number from being verified if it had already been previously been verified. However, with the overwhelming majority of users going through the intake being new, these pieces of friction were far less common. With an older user attempting to create a new account, they were able to verify with their phone number in this new intake despite it being tied to a previous account, and our admin system would automatically flag the old account as an alias.
Our multi-pronged approach also meant that we experimented with different touchpoints for new and current users, including at post-intake, at the profile, and SMS using a magic link.
above: Optional verification, order confirmation
above: Optional verification, post-intake dashboard view
OUR PERFORMANCE
Since we solely wanted to test for the performance of the phone verification, we held off on changing other factors within the intake. This meant that phone verification sat relatively late in the flow—right before checkout. With that in mind, users were already more inclined to input their phone number initially (pre-verification), as they had already completed many questions before that point, however, we wanted to see if additional friction (verification) would significantly alter these numbers.
With optional verification:
-
95% would choose to go through the flow
-
5% would choose to "verify later"
With required verification:
-
98.44% of patients verified and continued
-
1.56% drop off at verification screen
SimpleHealth’s business leaders were willing to make the tradeoff of a less than 2% dropoff for more secure patient communications and lessened load on our PX team. With this in place, we thought of future directions for growth, including 2FA and alternatives to our current magic link systems.
Design: Reginald Lin
Engineering: Anthony Fletcher
Copy: Devon Johnson, Reginald Lin
Thanks: Daniel Rigberg, Amy Pickup, Harmony Dashut