Users will find value in referring to the Allē program overall, instead of their specific offices. Due to compliance reasons, we are very limited in what we are able to provide for a specific office. This is to ensure that we aren’t seen as favoring one provider over another, or endorsing the way a provider operates. Therefore, users would be referring their friends to Allē as a whole, instead of a specific office. Would they be ok with this?

Patients are comfortable enough admitting they use our products to refer their friends in an official capacity. Because of the potentially sensitive nature of the industry, there was a question on whether users would be willing to ‘put in writing’ that they are an Allē member when they make a referral. While we know word of mouth is a major contributor to new patient visits, it isn’t clear how ‘hush hush’ those referrals are. Would patients want to be “on the record” as bringing in another patient to the practice?

Users will be motivated to change their behavior by the value of offers we are be able to provide. Due to the scale of Allē (7M+ members!), the budget impact of these referral offers could quickly get out of hand if we weren’t careful with the dollar amount. While our average Botox transaction is about $450, we have some customers who regularly spend $5,000+ at a time. Would patients be motivated by a $10 off coupon?

Providers would be on board. Providers have also noticed this word of mouth behavior, and many have introduced their own referral programs. As independent business owners, Allergan has very little control over how they manage their day to day operations, and participating in a new program of this type is always optional. Would providers embrace this program, even if they have their own? Would they discontinue their own? Would providers allow the same patient to be referred twice?

Data privacy team

One major hurdle of this project was getting buy in from our Data Privacy team. What we first assumed would be simple meeting to check a box, turned into a 3 month long iterative design process with senior management involved. After we first presented the user flows in Figma, they raised the concern that we would need a new data privacy opt in screen to disclose HIPPA sensitive treatment data from Allē member to Allē member. The terms of our program dictated that we were only able to reward the referrer once their friend makes a purchase. We would only deposit this offer in their wallet once their friends transaction cleared, or 48 hours, whichever was soonest. Therefore, if a patient only referred 1 new patient, and then watched their wallet very closely, they could tell the rough window of when their friend got treated. therefore, in the eyes of this team, the referred is disclosing their treatment data to the referrer. In our general terms and conditions, we do not ask for permission to share data between members.

This became a major roadblock in our release plan.

As we saw it, we had a couple path’s forward. We could change the way offers are deposited, and reward the referrer when a user creates an account instead of makes a purchase. This would satisfy the requirement from the data privacy team, but it would totally mess up our financial modeling. It would also open us up to a much higher risk of fraud, as a user could create 5 fake accounts and stack referral offers. For these reasons, we decided against this option.

We could change our general terms and conditions process to add this disclosure. However, while discussing this option, it became clear that with the new GDPR legal landscape, we would need to add a separate accept screen so users can choose to decline only this disclosure. In our eyes, this was worse than just asking the relevant users for this permission because it had the chance to impact our registration process, and already very lengthy process with high drop off. We decided against this option as well.

Ultimately we decided on adding an opt in screen during registration for users coming to Allē via a referral. This would add another step during their registration, but the impact would be limited to a relatively low count of users. We would include our copywriting team to try and make the language sound as non threatening as possible, while still meeting our data privacy team’s requirements. As I mentioned before, these products are often very personal. We aren’t sharing the date you got treated, the med spa or dermatologist you used, the products purchased, cost, points earned, or anything of the sort. Because of this, we felt this was the right path forward.

Issues with branch.io

During the course of this project, we had major concerns with a vendor we used to match referrer to referee - Branch.io. While we were testing the product internally, we found that branch was failing an astonishing 75% of the time. These users would click on the referral link as instructed, but Branch wouldn’t be able to grab the referral code from the link and pass it to the registration session. This would result in these users not recieving the offer as promised. Even worse though, is that because Allē accounts must be tied to a unique phone number, and patients rarely had 2 cell phone numbers, they couldn’t create a new account using that number again. Because referral offers are only available to new members, these users would actually ruin their opportunity to ever earn a referral award because of our mistake.

🤦

Our dev team tried for months to resolve this issue. We tried everything. Constant backend changes and iterations all resulted in the same outcome. We had countless meetings with branch.io senior developers trying to trouble shoot, all to no use.

This resulted in our release date being pushed back more times than I can count. A project that was intended to take 3-4 months ended up taking 10. Unfortuantely, we were the only ‘red squad’ in all of ADL for two quarters in a row.

In the end, we decided to work around this issue by pivoting to a code based approach. If Branch couldn’t grab the code from the link, we would just give branch the code directly. In practice this looked like changing our messaging from: Screenshot to: Screenshot. We would also provide an option to users to enter their referral code after registration from their Wallet for 7 days after registration. If the Branch linking did work as expected, we would auto fill the code for users once they arrived on that screen. That way, it looks like you always had to enter your referral code, and if the code is auto filled, its a pleasant surprise!

With these changes, we were comfortable moving forward with our pilot and wide scale release.