Referee discount
A benefit that may reduce the referred customer’s booking total when a code is accepted in the flow.
Limit: applying the discount does not automatically prove that the referrer’s reward is eligible or paid.
Help Centre · Referrals
How do you validate a referral reward?
Validating a reward requires distinguishing the discount already applied to the referred customer from the benefit still promised or recorded as paid to the referrer. This guide helps you reread the record, status, attribution, event, amount, and visible limitations before any authorized action.
Validate a reward without confusing the steps
Acceptance of a code may concern the discount applied to the referred customer’s booking; it does not automatically prove that the referrer’s reward should be paid. The referral line or record must be reviewed separately. Reread the status, attribution information, eligible event, amount, and limitations actually visible. A manual action is sensitive and must be performed only by an authorized person. Finally, a paid status describes what is recorded in the flow but proves neither retention, profitability, nor future revenue.
Three distinct elements
Distinguish the discount from the reward
The same flow may present several benefits. Their status and effect should not be confused.
Promised reward
A potential benefit or cost still awaiting review according to the visible rules and information.
Limit: a promised reward is not yet a reward recorded as paid.
Paid reward
A benefit recorded as paid in the management flow.
Limit: the paid status proves neither retention, profitability, nor future revenue.
Recorded status
Reread the current status
The exact labels and their availability may vary. Always reread the displayed status before taking an action.
Pending
The record is registered as pending in the flow.
Limit: this status does not specify on its own which conditions remain to be reviewed.
Paid
The reward is recorded as paid in the flow.
Limit: this status confirms neither the actual delivery method, retention, nor program profitability.
Rejected
The record is registered as rejected.
Limit: consult the reason when displayed; the status alone does not reveal which rule was applied.
Expired
The record is registered as expired.
Limit: the exact meaning depends on the visible or documented rules for the relevant program.
Conditions to review
Check attribution and the event
Use only the reference points actually displayed or documented in your flow. No code, link, or eligible event is universal.
Visible attribution
Event or condition
Conceptual flow
From identified record to reread result
Each step reduces the risk of confusing visible information with certain eligibility or a business outcome.
Record identified
The relevant referral line or record is opened.
Limit: opening the record does not prove that the reward is eligible.
Current status reread
The displayed status is reviewed before any action.
Limit: a status does not prove on its own that all conditions are met.
Attribution and event reviewed
The visible information linking the referral, people, and event is reread.
Limit: it may be incomplete and must be interpreted according to the applicable rules.
Amount and limits checked
The amount, reward type, and visible limits are checked.
Limit: no universal amount or cap should be inferred.
Authorized action performed
An authorized person uses the available action when the conditions are sufficiently established.
Limit: the presence and scope of actions may vary depending on functions and the flow.
Result reread
The status or message displayed after the action is reread.
Limit: the displayed result proves neither retention, protected margin, nor future revenue.
Related resources
Continue the review
Use the relevant product pages, tracking guides, and security resources.
Referrals
Learn about the documented functions related to codes, benefits, and referral tracking.
View the pageSurveys and recovery
Explore the guides devoted to customer experience and follow-up.
View the collectionHow do you move from a signal to a recovery case?
Learn the documented steps for organizing follow-up from a reviewed signal.
Read the articleHow do you prioritize a customer-recovery case?
Learn how to organize the handling order when separate follow-up has been considered.
Read the articleSupport
Contact supportDocument an unexpected result
Specify the page and flow, displayed status, reward type, amount when one exists, visible attribution information, relevant event or appointment, action attempted, exact result or message, approximate date and time, and a sanitized screenshot if useful. Never send a password, authentication code, key, token, technical secret, full payment number, or unnecessary personal information.