A referral reward is a customer promise with conditions. Those conditions need to be clear enough for a customer to understand and precise enough for marketing, finance, and support to apply consistently.
Use this checklist before launch and whenever an offer, return policy, integration, or abuse pattern changes. It is an operating worksheet, not legal advice or a guarantee that fraud will be eliminated. Have the appropriate legal and compliance owners review your final terms.
Agree on the reward rules
For each item, record the decision, owner, configuration location, and evidence from a test. An unchecked question is a launch dependency.
Eligibility
- Define who may advocate and what makes a friend eligible. Specify how new-customer status is checked.
- Document geography, account status, employee exclusions, and any age restrictions that apply.
- State the self-referral and household policy in plain language. A shared address alone may reflect legitimate customers.
- Define the fallback when a required identity or eligibility field is missing.
Qualifying conversion
- Specify the qualifying purchase or event, payment requirements, and product exclusions.
- Define the subtotal used for minimum purchase qualification, including discounts, tax, and shipping treatment.
- Document coupon stacking and how other promotions affect eligibility.
- Decide how full returns, partial refunds, cancellations, and chargebacks affect the referral and reward.
Attribution
- Confirm which tracking methods apply to your site and campaign configuration, and the data each requires.
- Record the applicable qualification window and how competing referral claims are resolved in your actual configuration.
- Test link sharing, coupon use, email changes, and any supported cross-device journey.
- Separate reporting attribution from eligibility to receive a reward.
Reward timing and limits
- Set the reward type, amount, approval timing, redemption conditions, and expiration.
- Choose a delay that reflects payment, cancellation, and return risk, then explain the wait to advocates.
- Define caps and repeat-reward rules. Confirm where they are enforced.
- Document the handling of already-issued or redeemed rewards after a later return. Do not assume they can be clawed back automatically.
Coupon and operational controls
- Decide whether codes are single-use, who can redeem them, and how they expire.
- Verify checkout enforces restrictions; a promise in campaign copy is not a checkout control.
- Monitor coupon inventory or provisioning failures and assign an owner.
- Define who can approve, void, expire, or override, and what evidence they must record.
In Talkable, referral approval and reward qualification are separate. An approved referral can still fail incentive criteria, such as a minimum subtotal or new-customer requirement.
See the official referral approval documentation. It describes pending-referral approval delays, separate handling for flagged referrals, and the role of incentive criteria. Match your customer-facing terms to the configuration you actually use.
Treat signals as reasons to investigate
Repeated account creation, unusual referral velocity, shared identifiers, coupon harvesting, and concentrated returns can warrant review. None is automatically proof of abuse. Shared households, workplaces, and networks can produce legitimate overlap.
Review only information your systems lawfully collect and make available. Do not assume Talkable has access to payment details or every device signal. Address-based checks, for example, require appropriate address data in the integration.
Illustrative review: shared address
Two customers share a delivery address. Check the published household policy and available referral and order evidence. If household participation is permitted and the other requirements pass, the address match alone should not be treated as a policy violation.
Illustrative review: repeated cancellations
An advocate has several referrals tied to cancelled orders. Verify order state and the reward timeline before acting. Escalate a recurring pattern, but resolve each record according to documented rules rather than assuming every connected customer acted improperly.
Assign an owner and response target for ambiguous cases. Review a sample of rejected referrals for false positives. Tighter controls that block legitimate customers can create their own cost.
A support decision tree
- Find the record. Verify the customer using your approved process. Locate the advocate, friend, referral, relevant order, and reward without exposing another person’s private information.
- Is the referral missing? Check the tracking method, identifiers, timing, and incoming purchase data. Escalate an integration issue instead of immediately issuing a duplicate reward.
- Is it pending? Compare its age with the configured approval delay. Explain the expected next step. Escalate records outside the normal window.
- Is it flagged or voided? Review the reason and supporting evidence against the policy. An authorized reviewer decides whether to uphold or correct it.
- Is it approved but unrewarded? Inspect incentive qualification, reward caps, coupon availability, and delivery status. Approval alone does not guarantee issuance.
- Has a reward already been issued? Check redemption and delivery before reissuing anything. Follow the documented exception process.
- Close the loop. Record actor, time, policy version, evidence, reason, and action. Give the customer a clear explanation and appeal route.
Talkable’s Customer Service Portal documentation describes customer referral and reward investigation. Confirm the actions available to each support role before adopting a workflow.
Pre-launch test cases
- Eligible friend, qualifying purchase
- Tracking, pending status, approval, incentive qualification, and delivery should follow the agreed sequence.
- Existing or otherwise excluded friend
- The result should match the campaign’s eligibility rules. Support should be able to explain why a tracked referral does or does not earn a reward.
- Purchase below the threshold
- The incentive should not issue, even when the referral itself is valid.
- Return before approval
- Confirm the return reaches the workflow and the referral receives the intended disposition before reward issuance.
- Return after issuance
- Verify the documented exception process. Record what can and cannot be reversed.
- Repeated event or coupon reuse
- Confirm duplicate processing and redemption restrictions in the connected systems. Check for accidental duplicate rewards.
- Shared household and manual exception
- Test the permitted and prohibited cases separately. Verify that an override leaves an audit record.
The tracking documentation notes that forced manual generation can skip fraud policies and incentive criteria. Treat such overrides as privileged exceptions, not a routine fix for missing data.
Copy-ready policy worksheet
Replace every bracketed field before customer use. These prompts identify decisions; they are not finished terms.
Participation: [eligible advocates] may refer [eligible friend definition]. [Self-referral, household, employee, geographic, and account rules] apply.
Qualifying event: the friend must complete [event] subject to [subtotal, product, payment, and promotion restrictions].
Attribution: participation must use [supported method] within [applicable window]. [Configured conflict rule] determines competing claims.
Reward: [benefit] is issued after [approval and incentive requirements], with [caps, expiration, and redemption restrictions].
Returns and cancellations: [rules before issuance] and [handling after issuance] apply.
Review and support: [brand review process], [response target], [contact route], and [appeal process].
Governance: [policy owner], [effective date], [version], and [exception approver].
Monitor controls after launch
Review pending-record age, approval and void rates, issued rewards, returns, coupon failures, support volume, resolution time, and overturned decisions. Break out the reasons for rejection rather than reporting every rejected reward as fraud prevented.
Reconcile to your commerce system where needed. Some measures require joined data outside Talkable. Do not label unissued rewards as proven savings, or estimate fraud loss prevented without a defensible method.
Revisit rules after changes in offers or return policies. Talkable’s approval documentation describes the Referrals API as one way to automate referral resolution. Confirm the integration and timing before relying on returns to void referrals automatically.
Frequently asked questions
What is the right approval delay?
It depends on your cancellation, return, payment, and fraud risk. Use your own data and support capacity, then monitor late returns and customer friction. There is no universal delay for every program.
Should every suspicious referral be reviewed manually?
No. Set a documented approach for routine cases and route ambiguous or material cases to authorized reviewers. Monitor the false positives created by automated rules.
Can a coupon be revoked after it is redeemed?
Do not assume so. What can be expired, reversed, or recovered depends on the reward type and connected commerce systems. Document the limitation before launch.
Does an approved referral always earn a reward?
No. Talkable checks incentive criteria after referral approval. Qualification, caps, and delivery are separate things to investigate.