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 do regarding 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?

Early iterations

Medium Fidelity

Higher Fidelity

Data Privacy team

One of the biggest challenges in this project was getting approval from our Data Privacy team. What we thought would be a quick, routine meeting turned into a three-month-long process involving senior leadership.

After our initial presentation of the experience in Figma, the team raised a key concern: the referral program could unintentionally reveal HIPAA-sensitive treatment data. Specifically, because referrers only receive their reward after their friend makes a purchase, they could infer when that treatment occurred by monitoring their wallet closely. This was seen as a privacy issue, since it meant one Allē member could indirectly access another’s treatment information—something not covered in our existing terms and conditions.

This became a major roadblock for launch.

We explored several options to solve this:

1. Reward on account creation instead of purchase

   This would satisfy privacy concerns but break our financial model and increase fraud risk, as users could create fake accounts to earn rewards. We ruled this out pretty quickly.

2. Update general terms and conditions

   This would require adding a specific opt-out for data sharing between users, per GDPR guidelines. That would further complicate our already high-friction registration process, so we also ruled this out.

Our solution:

We added an opt-in screen during registration for users joining via a referral. This keeps the change targeted to a small user group. To reduce friction, we worked with our copy team to make the language sound friendly and non-alarming—while still meeting compliance standards.

Importantly, we’re not sharing exact treatment dates, provider names, services, costs, or points earned; Just enough to trigger the referral reward. That made this the best balance between privacy, user experience, and business needs.

Vendor issues: Branch.io

One of the biggest challenges during this project was our vendor, Branch.io, which we used to match referrers with referees. While testing internally, we discovered that Branch failed to pass the referral code for new patients in 75% of cases. Patients would click on a referral link, but the code wouldn’t carry through to the registration session, meaning they wouldn’t receive their promised offer.

Worse still, since Allē accounts require a unique phone number—and most people don’t have more than one—those patients couldn’t just try again. Because referral offers are only for new members, our system essentially blocked these patients from ever qualifying for the reward again. All because of a technical failure on our end. 🤦

Our dev team spent months trying to fix it. We made countless backend changes and had many meetings with senior Branch engineers—but nothing worked.

This caused repeated launch delays. What was meant to be a 3–4 month project stretched into 10 months, and we were unfortunately flagged as the only “red squad” in ADL for two straight quarters.

Our solution:

We worked around the issue by switching to a code-based system. Instead of relying on Branch to pull the referral code from the link, we passed the code to Branch directly.

We also changed the user flow. Instead of relying entirely on the link, we told users to enter their referral code manually—either during registration or within 7 days after, through their Wallet. If the code did carry over via Branch, we’d auto-fill it as a nice surprise. This made the process feel intentional, not broken.

With this fix in place, we were finally confident enough to move forward with the pilot and full rollout.