A booking referral program needs a clear rule for recognising a new customer, a reliable record of completed appointments and a controlled way to issue and spend rewards. Loyalty offers use some of the same booking information but reward returning customers instead. Depending on what a UK service business already runs, the route may be software-as-a-service (SaaS) settings, a supported integration, a small change to existing custom software, manual administration or a different platform. Check what the system can actually record before promising customers a benefit.
In a typical scheme, an existing customer passes on a personal code, a friend enters it on a first booking, and each benefit is released once that visit qualifies.
Choose an offer the business can fulfil
Start with the action you want to encourage. Referral rewards suit a business seeking introductions from existing customers. Loyalty credit gives previous customers a reason to return; report the two outcomes separately.
A referral can reward the existing customer alone or both people. A welcome benefit for the friend increases the cost of each qualifying introduction. Fixed credit is predictable; percentage credit grows with booking value. A complimentary add-on uses staff time or materials, so check capacity before offering it. Minimum spend limits exposure only when it is set from the margin left after the reward, fees and service cost, and it adds a restriction.
Monthly referral limits cap the referrer's awards; welcome benefits need their own cap or budget, because one widely shared code can fund many discounts. An expiry date reduces open-ended obligations but gives customers less time to book, and, like any forfeiture rule, it must be fair and transparent under consumer law.
A hypothetical policy to adapt
Imagine a salon offering a welcome benefit on a new customer's first eligible treatment and a complimentary add-on to the person who referred them. The welcome benefit is reserved when the booking is made, used when the treatment is paid and released if the booking is cancelled; the referrer earns their add-on only after the new customer attends and pays. Existing bookings, complimentary appointments and previously registered customers are excluded. Each referrer can earn a single award in a calendar month; the earned add-on must be redeemed by the end of the following month. A refunded qualifying treatment removes an unspent referrer award, while any welcome benefit already used is dealt with under the published cancellation terms.
This is a design example, not a legal default. Test whether the system enforces the cap and expiry; otherwise simplify the offer or use manual approval.
Give referral attribution a definite answer
Decide what counts as a new customer across telephone bookings, guest accounts and different branches. For telephone and walk-in bookings, let staff record a verbal referral against the booking, with a claim deadline and their name on the entry. Before matching historical bookings or linking several contact details, document the purpose and lawful basis, explain the use in the privacy information and restrict matching to identifiers needed for that decision.
The policy must also settle competing claims. Decide whether the first valid code entered wins, how long a referral claim remains open, whether guest bookings can claim, and whether a referral travels between locations. Only named staff may reassign an attribution, with a recorded reason.
Generate referral codes with a cryptographically secure random source, rather than names or predictable booking references. Make each code unique, long enough that guessing is impractical, and revocable if it is exposed or abused. Validate codes on the server, limit repeated guesses and log suspicious attempts without collecting unnecessary personal information. Block self-referrals and repeated awards, but a household can share a device, phone number or email address: send uncertain matches to staff review, record the decision and give customers a way to have a wrong rejection corrected.
Track the friend's benefit and the referrer's award independently
The friend's welcome benefit may be available immediately at booking, whereas the referrer's award remains pending until the appointment qualifies. Each needs a separate status, expiry and cancellation rule. If a friend cancels, apply the welcome benefit's cancellation rule and leave the referrer's award unearned.
When an appointment is moved, preserve attribution only if the replacement still qualifies. Some systems represent a move as cancellation followed by a new booking reference. Link them through a stable internal appointment reference where the system has one, reconcile manually recreated or transferred bookings, and suppress a second award. Apply the published partial-refund rule; review spent awards without unexpectedly charging a stored card.
Where payment is part of qualification, verify each notification by the provider's supported method, such as a signature check or an authenticated request for the payment's current state. Record event identifiers so replays are ignored, and enforce one award per qualifying booking and reward type, because separate events can describe the same change. Events can arrive out of order, so check the current payment state before awarding: a refund or chargeback recorded first blocks the award, and one arriving later triggers a reversal.
Show customers a journey they can follow
- Find the code. The existing customer opens the reward section of their account and sees the code with the significant conditions. The code should identify their account without revealing personal details.
- Enter it at booking. Their friend supplies the code during their first qualifying reservation and sees any available welcome benefit. Check that the receipt shows the correct offer and that an invalid code creates no benefit.
- Attend and qualify. Staff complete the appointment and confirm the relevant payment record. The friend's benefit should move from reserved to used, and the referrer's award to pending.
- Receive an update. Each person sees only their own reward status and eligibility information. Check messages against marketing permissions before including promotional text.
- Redeem later. The referrer applies the earned add-on to an eligible new appointment. Staff and customer screens should agree, and a second use of the same award should be refused.
Tie loyalty to services that actually happened
A loyalty scheme should award credit from completed eligible appointments, rather than account logins or reservations that can be abandoned. Decide how combined treatments, free appointments, staff-entered bookings and refunded visits count. A visit-based reward is simple to describe; a credit balance can handle varied services but needs more adjustment and redemption controls.
Specify whether a referred customer's first visit also earns normal loyalty credit and whether a booking paid partly with referral credit can earn further loyalty benefits. Customers should see pending and usable balances separately, including any expiry before they book.
Test an appointment completed at reception after being booked online. Staff and customer balances must agree with one authoritative, reconciled record, whether that is the platform or a managed export.
Compare booking software with the intended rules
The word "referrals" on a feature list can describe anything from a free-text field to an automatic wallet. Bookwhen's published process uses a booking field, exported booking information, a customer lookup and discount codes issued manually; its help page explicitly says new-customer discounts are not automatic. Check which plan includes discount codes and any limits on combining them. Fresha's Client Loyalty is a paid add-on with a customer wallet, referral link, reward claims and a separate referrer reward after the friend's completed appointment. Any invite button that sends messages through other apps needs the PECR check below before it is switched on.
Look at event triggers, guest support, staff adjustments, reporting access, cancellations and the supplier's shutdown procedure. A supported integration needs accessible booking events; a custom change needs code access. The separate custom booking system and SaaS comparison covers the wider platform decision.
Configuration checklist
- Record what exists. Export the available booking and reward records, save offer wording and capture current settings. Confirm whether the supplier provides a real backup and a tested restore; an export or saved screenshot is not a restore facility.
- Check account entitlement. Read the supplier's help instructions for the feature and subscription in use, then create a synthetic booking in a test environment if available. Identify what actually triggers each benefit.
- Set the policy. Configure eligible services, limits, expiry, reward status and staff permissions. Check every setting using a test customer and stop if a required condition cannot be enforced.
- Exercise failures. Test incorrect codes, cancelled and moved appointments, late payments, refunds, repeat completion events and simultaneous redemption.
- Check the off switch. Ask the supplier what happens to earned points, tiers and refunds if the scheme is paused. Record the documented procedure before activation; disable new awards if a test fails, without deleting earned customer entitlements.
Fresha states that disabling Client Loyalty preserves existing points but removes tier access and tier rewards; it also says refunds do not automatically deduct points. Check these behaviours in the account you use and plan manual reconciliation where needed.
Build a ledger that prevents duplicate earnings and spending
For custom software, store referral attribution, the policy version, qualifying booking, separate customer and referrer reward states, and an audit history. A loyalty ledger should record each earning, redemption, reversal and authorised staff correction. Derive the visible balance from those records or from a summary updated under the same controls; overwriting a balance alone makes disputed changes hard to explain.
At the database layer, enforce a unique key for each earning event and another for each redemption event. A transaction alone does not prevent duplicate awards when repeated requests take different paths. Repeated completion messages should return the existing award.
Double spending is a separate problem. Two checkouts must never redeem the same available balance. Within one database transaction, take a lock on the relevant balance or use a conditional update that succeeds only while enough credit remains; write the redemption and updated balance together. Where a reward is applied when an appointment is reserved and settled later, reserve the entitlement in that same transaction and release it if the booking is cancelled or checkout fails, so two pending bookings cannot claim one reward. If the caller loses the response after commit, check its redemption event key before retrying rather than subtracting again.
Test duplicate requests and simultaneous checkouts with synthetic or anonymised data. Protect and restrict access if production data must be copied. Verify exactly one earning or redemption for each valid event.
Limit personal data and contact permissions
Booking records and referral histories contain personal data. Under UK GDPR, use an appropriate lawful basis, collect information proportionate to the stated purpose, limit staff access and justify how long each record stays. Running the scheme, detecting abuse, analysing customers and promoting offers are separate purposes; assess each before reusing booking history for profiling or marketing. Avoid importing friends' address books, retaining unnecessary identity evidence or treating referral attribution as proof of marketing consent.
Test whether staff can locate a customer's linked reward records for an access or correction request without deleting records that have a lawful reason to remain. The wider GDPR obligations for booking systems need a separate assessment when processors or messaging providers handle customer data.
Referral codes are not permission to send advertising
The ICO's electronic mail marketing guidance explains that a business can instigate promotional emails or texts sent by its own customers. Encouraging customers to forward marketing or supplying a prewritten invitation can bring the business within PECR, even if a customer presses send. Displaying a code in the customer's account without instructing them how to share it is a lower-risk design.
Check a platform's built-in invite or share feature against PECR before turning it on; being built in does not make it compliant.
The product-and-service soft opt-in requires contact details collected directly from that person during a sale or negotiation, marketing about similar services, and an opt-out when details are gathered and in every later marketing message. A friend's address supplied through a referral form, or details collected by an intermediary or another platform and passed to the business, do not satisfy that direct-collection condition. Appointment confirmations and essential service messages must remain purely administrative; a message promoting the reward scheme is marketing and needs its own permission assessment. These consent rules protect individual subscribers, sole traders included; messages to corporate addresses still need the sender identified and a valid address for opting out.
Publish fair terms and leave reviews out of the scheme
The ASA and CAP's guidance on significant promotional conditions says conditions likely to affect a customer's understanding belong upfront in the initial promotion, including eligibility restrictions and relevant limitations. Show who qualifies, the earning event, excluded services, minimum spend if any, per-customer caps, expiry, existing-booking exclusions, location limits and what happens when the offer closes. Put applicable significant terms in the promotion itself and at joining, not solely behind a terms link. A very short advertisement still has to communicate as much significant information as practicable.
The Competition and Markets Authority's unfair commercial practices guidance also addresses misleading promotions and prohibits concealed incentivised consumer reviews. A private recommendation to a friend differs from a public post: a customer who publishes their referral code to earn a reward is advertising for the business, so that connection must be clear; do not disguise the post as independent opinion. Google's own review policy goes further: businesses must not offer any benefit for a Google review, even with disclosure. Never award reviews through a referral scheme.
Before customers join, decide what closure means: stopping new sign-ups, honouring rewards already earned until their stated expiry, and applying a new policy version only to rewards earned after it starts. Show pending status honestly rather than saying a referrer's benefit is already available. Seek UK legal advice on unusual restrictions or disputed rights.
Measure completed referrals and genuine return visits
Set the reporting window before launch. As an example, group first bookings made in a calendar month, credit the first valid code entered before booking, and allow until the end of the following month for attendance. Completed-first-visit rate is completed eligible first visits divided by all valid code-attributed first bookings in that cohort; it measures attendance after a referred booking, not how many people who saw a code went on to book. Cancellations remain in the denominator.
For repeat-customer rate, take customers who completed an eligible visit in the starting month and measure the share who return by the end of the following calendar quarter. Adjust the window for services with longer gaps between visits, and compare only like services and cohorts whose full window has passed. Where referrals and loyalty overlap, give acquisition credit to the referral once and count later completed visits in retention; record both reward costs against the relevant booking. Code-attributed does not mean caused: some customers would have booked anyway or found the code at checkout.
The booking server should record code accepted, booking created, attendance confirmed and reward redeemed, with event identifiers that allow reconciliation. Website analytics may record code views or link clicks. Non-essential visitor tracking and cookies used for those measurements generally require PECR consent; the ICO's narrower exception for aggregate statistics used only to improve the service requires its own assessment and an easy objection route.
Calculate contribution for an attributed booking from the amount actually paid after the friend's discount, minus the referrer's reward, platform fees and the cost of delivering the service, with VAT treated as your accountant advises. Note unused rewards separately. Pending credits describe operational reward exposure; formal accounting and VAT treatment depend on the scheme, so obtain accounting advice if it becomes material.
A random holdout assigns eligible customers, not single bookings, to receive no offer, although shared codes can still reach them. Month-to-month comparisons remain observational. Small numbers, seasonal patterns or long intervals between visits can prevent a credible conclusion. The separate guide to booking system analytics covers wider appointment measures.
Release with a shutdown and reconciliation plan
- Approve the rules. Compare the customer offer, staff procedure and system settings, including what happens at closure.
- Protect the existing service. Take a restorable backup where you control the data; record any supplier-supported export and shutdown limits. Prove the recovery route using an isolated environment before altering live bookings.
- Run acceptance cases. Exercise a new referral, guest booking, competing code, reschedule, refund, chargeback, duplicate event, simultaneous redemption and manual correction. Inspect bookings and both reward histories after each outcome.
- Start narrowly. Enable the scheme for a limited eligible group if the platform supports that restriction. Confirm ordinary bookings still work without a referral code and that customer-facing conditions match the agreed policy.
- Reconcile and respond. Compare completed visits, earned rewards, spent balances and refunds with the source records. If totals diverge, pause new awards using the supplier's documented procedure, preserve earned balances, and reopen only after corrections are checked.
Agree the earning event before switching anything on
Write down which completed booking creates the award and which refund or cancellation takes it away, then prove both cases in a safe test. For help changing an existing custom PHP booking site, you can ask about the change through a short call followed by a written quote. Do not enable a booking referral program until earning and redemption checks agree with its published terms.