A Multi-Branch Referral Programme Attribution Model That Survives Customer Transfers

Referral programmes become hard to evaluate when a referred customer discovers one outlet, contacts a second and purchases from a third. Crediting the final branch alone hides the role of the referrer; crediting the first branch alone can ignore the team that completed the sale. The answer is not to force every organisation into one attribution rule. It is to define the business question first and retain the underlying events.

Separate referral origin from fulfilment

Capture the referral code or campaign identifier, the date it was first accepted, the branch selected by the customer, the branch that completed the sale and the transaction status. Keep these fields immutable after the fact where possible; corrections should be recorded as amendments with an audit trail. A staff member should not be able to overwrite the referral source simply to improve their outlet's score.

For a small retail chain, the referrer may receive a reward based on the first qualifying purchase, while branch revenue remains with the outlet that fulfilled the order. For a healthcare group, referral rewards may be inappropriate or restricted by professional, contractual or regulatory rules; do not transplant a retail incentive model into a sensitive sector without legal review.

Choose one of three crediting rules

Rule	Appropriate question	Main risk
First accepted referral	Which activity introduced the customer?	Overcredits discovery if the lead never converts
Converting branch	Which outlet fulfilled the qualifying sale?	Hides cross-branch assistance
Split operational credit	How did multiple branches contribute?	Can double-count totals if credits are summed as revenue

If split credit is used, label it as an analytical allocation, not accounting revenue. The finance ledger must still record the transaction once.

A transfer example

A customer receives a referral from a Pune customer, submits the form while viewing the Nashik branch page, calls a central number and purchases in Mumbai. The referral origin is the code; the selected location is Nashik; the contact route is central; the fulfilment location is Mumbai. These should not be collapsed into a single “branch” column. If the CRM cannot store all four, create a controlled event table rather than overwriting the original lead row.

Fraud and fairness controls

Define duplicate rules before launch: self-referrals, repeated codes, cancelled orders, returns, staff referrals and household referrals may need different treatment. Use a cooling period only if it is part of the published programme terms. Keep an appeal path for branch teams when routing changes the attribution.

Review referral conversion by cohort, not just by branch totals. A branch receiving more transferred leads may look productive despite doing little acquisition work; a branch that generates referrals but lacks stock or appointments may look weak under a conversion-only score. Show source generation and fulfilment as separate dimensions.

Source notes

• Internal editorial framework: Proposed referral attribution workflow; validate against relevant contracts, policies and applicable law..