Understanding the KPIs

25 net referrals per 100 active customers a month is the customer base producing new customers equal to a quarter of its own size, every month.

What your 30-day K cannot see

Compare your 30-day K with your monthly net referral rate: someone in their first month refers at about the same rate as anyone else. Customers in their first 30 days are only a slice of your customer base. Your 30-day K counts referrals from that slice and nothing else. I would want to know what share of your active base is in its first 30 days, because that number tells you how much of your referral activity your primary KPI cannot see.

30-day K prefers velocity versus overall referral volume. A loop that turns in 30 days compounds far faster than the same loop turning in six months. I would own 0.30. What is missing is that nothing in the KPI set measures what causes a referral in the first place.

When referrals actually happen

Your own numbers say it is not the checkout moment. 1.21% share within 1000 seconds of paying, and the average first referral at 26.8 days.

The 30-day window sits on the weakest part of treatment. Both medicines hold the starting dose for four weeks before the first increase, so every patient your 30-day K measures is on the lowest dose they will ever take, for the whole window. Whatever they have to talk about by day 30, they have it before the medication has properly started.

Potential referral triggers

Besides prompts, there are two potential candidates for what triggers a referral.

• Your reviewers who say why point at the service: the delivery arrived, the process was easy.
• My nine years as a clinical nutritionist point to fat loss results. Most client-to-client referrals in my practice happened when trust in the service builds, and results start to show.

Find where referrals cluster

For the service side of the referrals, take the 26.8 days and look at its shape: one cluster means one moment and one well-timed ask. Two clusters mean two different groups referring for different reasons. Plot the distribution against every dated event you hold: approval, dispatch, delivery, support contact, reorder, referral prompt to find the trigger to optimise around.

For the results side, your app already has a weight tracker, which is purportedly in beta. If not already done, I'd connect it to when the referral ask fires and see if there is correlation.

Clarity on the shape of referrals as they are now will give you what to build and optimise for.

The current referral system at Bolt

Evidence taken from your referral page and Trustpilot reviews

https://www.boltpharmacy.co.uk/referral-programme

A. Capture friend contact at the outset

Ask the referred friend to claim the discount with their WhatsApp number or email as the first step. Yes, it is an ask before delivering any value, but a smaller one than requiring immediate onboarding and purchase.

Should they abandon the signup process, Bolt now has a point of contact to send reminders to. For attribution, if they return and register on another device, match them by contact.

I'd also consider shortening the discount claim window for referred friends from 6 months to 30 days, to bring signups and purchases forward.

The Flow

The Screens

B. Instrument the referral funnel

Instrumenting the digital referral funnel with 9 events:

• Three for the existing customer sending a referral link
• Six for the referred friend claiming, onboarding, paying, and receiving their first order

This makes it clear where the funnel breaks, so fixes can be designed against the break point.

The above 9 events are joined by 4 ids that hand off in sequence: account_id, share_id, claim_id, order_id. The claim_id is written from the WhatsApp number or email the friend typed at the claim, so it survives a device switch and a refused cookie banner because the friend gave you the contact rather than being tracked.

Every event is written by your own backend to a database; at the moment it writes the row that caused it, so there is no tracking script to fail. The events live in the same database as the claims.

As far as I am aware, analytics tools like Amplitude or Mixpanel can connect two visits only when both visits carry an id you gave them. Your customer is signed in, so their visits carry one. The friend is a stranger. They tap the link on their phone carrying nothing, and if they sign up on a laptop three days later that looks like a brand new person, with nothing pointing back to the phone. Asking for one contact at the claim is what creates the link. It belongs in your database rather than a vendor's, because that same row is what decides who gets paid. Your database decides who is one person, and every event carries that answer with it.

Two numbers will mislead unless they are built carefully

• Link clicks. Not every click is a person. As soon as your customer pastes the link into the WhatsApp message box, WhatsApp opens it to build the preview card, before the message is sent, so your server records hits for links that never reached anyone. Those are easy to spot and drop: they announce themselves as WhatsApp and never run any JavaScript. Corporate email filters are the harder case, because they open links to check them for phishing and many look like an ordinary person browsing. Strip out the machines you can identify, then read click-to-claim as a rough guide rather than a headline number.
• Match rate, the share of registrations correctly joined back to their claim. The join relies on the friend registering with the contact they claimed with, and it fails in exactly one way: they use a different one. Two things narrow that gap, a disclaimer on the claim screen telling them to register with this same contact, and a flow that gets them through the consultation in one sitting.

C. Allow users to claim referrals seamlessly (Supabase build)

GitHub link to the build: github.com/joleneann/bolt-referral-tables

Attributing and releasing every referral discount cleanly, once every condition is met, is a priority. Assuming you require a unique email and phone number for every customer, the data points left to de-duplicate before a referred friend's first purchase are

• first name
• last name
• address line
• postal code

That is 16 permutations; only 4 need a human to look at the ID verification record, as these could be an existing customer opening a second account for the new-customer discount.

The cases your reviews flag as trouble today, husband and wife or housemates at one address, are resolved by this system, with every decision logged. This could cut the support time spent on manual fixes when the system breaks.

The system also ensures the correct reward amount is released, that no referrer ever gets a second £80, and that no friend's discount is released twice.

D. Content engines for education, adherence and retention

You collect at least 13 structured data points from every customer during onboarding, and I'd use them to send short-form personalised content signed off by the clinical team. The starting library won't be large; one piece can go to many customers.

Educated customers find adherence easier, retain longer, get results, and potentially refer more. The pieces can also be made shareable, with the shareable versions removing medicine names to comply with regulations.

E. Digital app for Bolt

Bolt’s digital surface, a mobile app with 4 tabs:

• a medicine tracker
• a home for the content pieces to land
• a progress and habit tracker
• an account page primed to send referrals through

The first tab sets GLP-1 dose reminders, prompts refills, and can track their other medications too. Learn serves one content piece a week and ends by offering a matching habit to add to the Track tab, which also logs their weight loss progress. On the referral tab, customers can send friends a primer on GLP-1s along with their referral link.

Early experiments

You ask to improve the referral programme fast through experiments, and bring a clear process for generating and prioritising them. Every experiment below is aimed at increasing how many additional users each existing user successfully invites and carries a kill rule and most have a cited precedent or research.

Notes

1. Give-only option, customers give all £80Growth lead Daphne Tideman has cited how she referred more on BetterHelp, an online therapy platform, once a give-only option existed (gift 2 weeks of therapy, keep nothing). Reasons given was it felt less like selling, and the additional money gave a friend more time to try the offering.
The Journal of Marketing Research (2020) backs the mechanic: rewards given to the friend recruited more customers than rewards kept by the sender, at the same cost to the company. The caveat is that it may attract more bargain hunters who don't retain well.

2. Friend education kitFriends ask a customer with visible results "what did you do?", and many customers have no comfortable answer ready. The kit is a clinician-approved answer they can send. The question is common: in a BMJ Public Health survey (2025, 1,297 UK adults), 28.5% first heard about these medications from friends and family, against 9% from healthcare providers.

3. Different ask sequence for referred usersA referred customer knows people can talk about this treatment, because someone talked to them about it. They can be prompted to refer earlier, and possibly more often and observe how it fares.4. Card in the monthly boxA box reaches every paying customer every 4 weeks. A card congratulating them on their progress, with a scannable referral code could prompt them to refer, especially if it's observed that existing referrals cluster around delivery. Referral links could also be sent on email and Whatsapp as part of the delivery message.

5. Personalised content engineA Danish national registry study of 77,310 people starting semaglutide for weight loss found 31% stop within 6 months and 52% within a year, and that is in a cheaper access context than UK private pay. There are some complaints on Reddit of a lack of a structured education or behaviour programme. Pointers from the onboarding questionnaire are used to deliver relevant short-form content. LTV and retention of exposed users measure whether it works.

6. Referred friend updatesToday a customer hears nothing between their friend's claim and the credit arriving. Your reviews show that gap: "over 30 emails", "a week of emailing to and fro" to activate one credit. A status view in the app closes it: the customer sees each referral as claimed, delivered, credit released. It shows nothing more, because the friend's order details are the friend's data likely protected by GDPR laws. If a privacy review rejects even that summary, this dies.

7. Claim-first contact captureYour own terms say "if they navigate away or switch to a different device before purchasing, the referral won't track." Hims & Hers closes the same leak by tying the credit to the account the friend creates, so the referral survives a device switch. The test decides whether asking for contact up front turns away more consultations than it recovers in referrals.8. Friend's discount worded 3 ways

Every version is the same £40, worded as £ off, a % off, or account credit. The precedent is in the same CXL course: Heights, the supplement brand whose growth the course instructor ran, tested £15 off against 15% off for the same discount and saw results. Wording is free to change, so this is a cheap test.

9. Claim window, 6 months vs 30 daysShorten the friend's claim window from 6 months to 30 days. A shorter window pushes the friend to decide, and 2-3 reminders with a clear opt-out educate and remind the user. Kill switch is the shorter window converting worse.10. De-duplication systemBolt does not publish what its duplicate check matches on, but reviews show the customers it refuses share one pattern: two people at one address. This build separates a shared address from a shared identity with a human in the loop for certain cases. Kill switch is rising support ticket burden pertaining to deduplication and referral payouts.

About Me

I am a clinical nutritionist and growth marketer who builds with AI.
Here is my LinkedIn

You ask for someone who iterates faster than most product teams can finish scoping. Evidence of this ability is this document, with the referral tables running live on Supabase, the referred friend journey, the content engine, and the app screens.

Some of my past work, relevant to the role

A. ScopeX

We grew ScopeX Fintech from under 100 paying customers to more than 25,000 in under 12 months. Making referral our main source of growth was largely my decision after viewing the numbers. The tactic: a referral offer placed at the product's natural sharing moments. The result: roughly 40% of new customers arrived through referral, converted best and stayed longest.

B. My clinical nutrition practice

Since 2017 I have run an independent clinical obesity practice working with a GP and a psychiatrist, with about 250 clients. Effectively all of them arrived through 1:1 or GP referral.
This experience helps me understand the customers you work with: people with obesity, on treatment that changes appetite and mood, and how they adapt and adhere to treatment.
My clients generally referred when their results first became visible, which is consistent with your 26.8 average days to first referral.

Recently I created software with Next.js and Postgres which helps practitioners like me reduce marginal time on client consults with AI, and helps clients adhere to prescribed lifestyle interventions.
A 10-section intake adapts as the client answers it. AI drafts the treatment plan, and the clinician edits and approves it section by section. The client tracks habits and measurements daily. This was the build that fed into the freemium app idea I built out for Bolt.

C. Pawkit

My most recent project for a veterinary clinic helps clinicians manage their inboxes, stay in touch with pet parents between appointments and send them relevant pet health content by segmenting their client list in the language of the client's choice. Voice AI helps the veterinary physician take appointment notes, maintain a lifetime pet health record and use a RAG system integrated with up-to-date veterinary research data for diagnosis and treatments. A part of this buildout can be viewed here.

The first 90 days

Days 1-7: My first job is to learn Bolt's existing systems and growth factors today so nothing of what I build disrupts them. I walk through customer journeys first hand and write down each moment that feels dead, slow, confusing or magical. The same week I ask the people who built and run the current programme two questions: why are we growing, and if you were in my shoes, what would you do first. What looks broken to me may be holding something up; I find out which parts those are before touching any of them.

Days 2-30: Set up and run easy experiments which don't break existing channels. Look at existing analytics and measurement infrastructure and add/build what's missing.

Big bets. I build a big-bet list from week 1 from my observations. From day 30 I take the strongest bets to the clinical, product and engineering owners and ask them to kill each one. This is regulated healthcare. A growth experiment shipped without clinical sign-off is a compliance failure, even when it moves K. A bet nobody can kill gets built.

By day 60: I put the growth plan on one page: the route from K 0.0835 to 0.30, which factor of K we attack in which quarter, what gets built next, and what stays parked until the core loop moves. I write it in my first 90 days on purpose, while I still see the product as an outsider, and I expect the first draft to be about 70% right, so I revise it weekly as experiment results land.

By day 90: a trusted K baseline, the first experiment cycle complete with kill rules honoured, the big bets validated or killed, and the strategy current.