A reward patients can use, and a program hospitals can run
LeapHealth's B2B loyalty and referrals platform. Patients earn points on one visit and spend them on the next; I designed the program that keeps that promise dependable across units and billing systems.
Impact
This platform is live. It has run in production at a large maternity chain since August 2025, and the figures below are from that platform as of October 2026. The customer's name is kept out; the numbers are real, not projections. The economics behind them, including who actually redeems, what it costs the hospital, and what is still unproven, are in Outcome and impact at the end.
Context: a simple promise with a complicated middle
Loyalty is a marketing vertical at LeapHealth: a patient buys an eligible service, receives points, and uses them later for a cash benefit. The patient hears one promise:
The points I earned today will help me next time.
Behind it, one point travels across days, units, staff and billing systems:
Referrals add a second timeline on top: a code is shared, a lead captured, a bill paid, and a reward matures only after a milestone. The job was to make all of it feel like one dependable program, while marketing keeps the freedom to change strategy.
Case study note: this journey is reconstructed from the final product and my account. The screens show what was designed; they do not record the chronology of workshops, interviews, concepts or testing.
Discovery: finding the real UX problem
Working backward from the finished product, four needs shaped the experience. They are read from the workflows, not quoted from research participants.
Points arrive two ways. A staff action at the counter, or a bill export from billing.
So the product had to Work without a single point of sale or one perfect integration.
A balance is a mix. Newly earned, spendable, redeemed and expired, all at once.
So the product had to Never answer with "total points" alone.
Spending is a process. A lock, an OTP, a receipt code, a bill attached later.
So the product had to Treat redemption as a trusted transaction, not a subtraction.
A referral is a journey. Capture, attribution, approval, then milestones.
So the product had to Manage it end to end, exceptions included, not just hand out a code.
The real problem was not "patients need more discounts": patients need to remember and trust a future value, and staff need to apply the program without carrying its rules in their heads.
How might we make points earned at one visit understandable and usable at the next, while giving marketing and operations the control to manage that promise at scale?
Principles that shaped the solution
Inferred from the patterns in the final screens; the original team's wording may have differed.
From problem to product architecture
Seven design moves, reconstructed from the finished product rather than a record of the order they were explored in.
Move 1: Map every state of a point, not just earn and redeem
Earn-to-redeem misses the waiting and the reasons points disappear. The full lifecycle:
12345
Reward points works the award out from the bill and the earning rules before anything is credited; Redeem points starts from what is usable now and locks it.
Design decision: the balance a patient sees is backed by explicit states and rules: expiry, a waiting period, rounding and per-event ceilings on the way in; holds, limits, daily guards and reversal policy on the way out.
Move 2: Separate campaign logic from transaction entry
If staff had to remember which service earns what, every campaign would make the counter harder. Instead, a bill goes through:
Earning rules in one list, highest priority first; a rule reads as a sentence: what the bill has to match, what it awards, and when those points expire.
Design decision: a marketer configures eligibility once; the operator enters a transaction and sees the result.
Move 3: Design for the billing environment that already exists
1234Move 4: Close the loop when points are spent
Redemption is a bill-linked event, not an unexplained drop in balance:
Move 5: Bring the benefit back to the patient between visits
The reward has to stay visible after the patient leaves. WhatsApp templates are wired to the moments that change a balance, each with allowed days and send windows, and a warning when a template's variables don't match:
1234Design decision: communication is part of the points lifecycle, with delivery evidence for troubleshooting. The screens do not prove reminders caused a return visit.
Move 6: Extend the same accountability to referrals
A referral reward cannot be reduced to "share a code". Its journey, with value released only at milestones:
A program spells out who refers, where, for how long, and what each milestone pays both sides.
Leads with a next action on every row; adding one starts with a choice: a new ambassador, or someone referred with a code.
Conflicts wait for a person instead of resolving silently; the referrer view separates top, one-and-done and lapsed referrers (example data).
The referral product launched in Aug 2026 but still carries only pilot and test volume, so these screens show the designed management flow, not live conversion results.
Move 7: Give teams a way to see, investigate and correct
A points dispute should be answerable without guessing history from a balance:
Logs answers "why did this balance change?" across every patient, reversals included; fraud rules decide what gets flagged and what is held.
The dashboard shows activity, not retention impact. The fraud settings and holds shown are example data; in the live console fraud detection is optional, so these are described as available safeguards.
How the interface distributes complexity
So much configuration could swamp the person serving a patient. The structure separates three kinds of work:
Loyalty settings keep Redemption, OTP, Receipts, Accrual, Notifications, Centres, Earning caps and Referral on separate tabs: deep configuration, kept away from the most common patient action. There is no usability evidence yet that this reduced task time or training.
Outcome and impact
The final product connects point policy, individual and bulk accrual, patient balances, redemption, WhatsApp communication, referrals, receipts, monitoring and audit trails. It gives marketing a way to create incentives for future engagement, and gives operators the means to fulfil and explain them.
The headline numbers are at the top of this case study. When it was first written none of them were established; the program has since run in production, and what those numbers cost, who actually redeems, and what is still unproven are the parts worth sitting with.
The quiet economics: a benefit that mostly costs nothing
For a hospital the useful number is not points handed out, it is points actually spent. Bill points expire in 60 days and most are never used, so the real cost is the discount the program funded, not the liability it printed.
Who actually redeems
Redemption is not spread evenly. It climbs steeply with how often a patient returns, which is the behaviour the program was built to reward:
| Rewarded visits per patient | Share who redeemed points |
|---|---|
| 1 | 0.0% |
| 2 to 3 | 0.5% |
| 4 to 5 | 3.4% |
| 6 to 10 | 11.5% |
| 11 to 25 | 34.5% |
| 26 or more | 74.7% |
Patients who come back often are far more likely to use their points: 51% of those with 11 or more visits redeemed, against 10% overall. This is a correlation. The data cannot prove the points caused the visits, only that the two move together.
Reflection
The biggest lesson: loyalty is a promise stretched across time, and every part of the product holds one piece of it.
Designing only the points balance would have missed most of the experience.
Where this case study goes next: replace the reconstructed discovery with the actual project story, the original brief, whom I spoke to, constraints from hospitals and billing systems, concepts I changed, testing feedback and my exact contribution. The validated production results now live in Outcome and impact above; the design process is the part still told as a reconstruction.
Thanks for reading.