A guest who changes a phone number or email can recover a loyalty account by proving ownership through an approved alternative, then asking an authorized staff member to update the identifier. If the evidence is not strong enough, the safe outcome is a manual review—not a guess based on a name or an old number.
When buying restaurant software, ask the vendor to show both paths. The process should help a legitimate member regain access without showing another guest’s rewards or transferring them to the wrong person. It should also leave a record of who approved the change.
Account recovery is different from merging duplicate profiles. Recovery verifies ownership before changing a contact detail on an existing account. A merge combines records and may need its own approval and correction rules.
Start with the guest’s recovery request
Imagine a regular guest says, “I have a new phone number, and I can’t receive a code at my old one.” The immediate question is not how many points to move. It is whether the person making the request owns the existing account.
Separate what staff can observe from what the guest reports. A guest may provide an old number, a new number and a name. The system may show that an account matches the old number. Neither fact alone proves ownership: phone numbers can be reassigned, and someone else might know the guest’s details.
Use the following hypothetical example to build your decision worksheet. The figures and rules are assumptions for comparing workflows, not descriptions of any vendor’s product.
- Request: A guest asks a cashier to replace an old phone number with a new one. The guest supplies both numbers in person.
- Record: A profile matching the old number shows 480 points and an email address already on file. The displayed point balance comes from the restaurant’s loyalty record.
- Access: The guest says they can still access that email. For this example, the restaurant accepts a successful verification through a previously established email as one approved proof method.
- Reward rule: Assume 500 points can be redeemed for one $5 reward, subject to the program’s rules. At 480 points, the account does not yet have that redeemable reward.
The 480 points are worth $4.80 only as a proportional equivalent under that assumed rate. They are not a $4.80 reward the guest can necessarily redeem. Ask your vendor to show the actual balance, available rewards and expiration rules separately.
For context on how earning and redemption rules fit together, see what a restaurant loyalty program includes. Recovery should preserve those rules rather than quietly creating a new entitlement.
Compare proof and staff access before choosing
Your worksheet should compare what happens when proof is available with what happens when it is not. The example below assumes the email was already associated with the account before the request. A newly supplied email would not, by itself, prove ownership.
| Situation | Proof available | Action | Outcome |
|---|---|---|---|
| Guest can use the email already on file | Verification through that email succeeds | Authorized staff update the phone number and record approval | Guest keeps the existing 480-point balance; no reward is issued |
| Guest cannot use the old phone or existing email | Only a name and old number are offered | Do not change the identifier; send the request to a manager | Account stays unchanged until an approved review is completed |
The difference that changes the choice is access to an established proof channel, not the size of the balance. If neither old contact method works, ask the vendor what other evidence your restaurant can configure or review. A receipt or order detail may help a manager investigate, but decide in advance whether it is sufficient; information about an order can sometimes be shared or guessed.
Keep the first staff view narrow. A cashier taking a request may need to know whether it requires review, but may not need to see the full profile, contact details or reward history. Ask whether roles can restrict who may search, view balances, change identifiers and approve exceptions. If the system cannot separate those permissions, decide whether a manager should handle the entire recovery.
Also ask what happens if the new phone number or email is already attached to another profile. The recovery should pause for review rather than automatically taking over that profile or merging accounts. A manager can then investigate a possible duplicate using a separate process.
Demonstrate the failure case without exposing rewards
Ask the vendor to stage a simulated recovery in a demo or test environment. Use fictional profiles and contact details controlled for the demonstration. Configure or simulate the flow so it sends no guest message and triggers no real payment or courier dispatch. This is a practice check, not a live service pilot.
Create two fictional profiles with similar names. Put different point balances on them. Have a cashier search using information that could plausibly match either profile, then request a phone-number change without completing approved proof. The cashier is the role that should detect ambiguity and stop the request; the manager is the escalation owner.
Pass: The cashier cannot complete the change or reveal the other profile’s rewards before the required verification or approval. The request is routed or recorded for manager review, and both profiles retain their original identifiers and balances.
Fail: The system changes an identifier on a partial match, exposes the other profile’s reward details to the requester, or allows the cashier to bypass the required approval. It also fails your workflow if the result appears successful but the record shows a different account was changed.
After the simulated attempt, have the manager inspect both fictional records and the change history. Looking only at a success or error message can give a misleading result. Check the account identifier, contact field and balance before and after the attempt. If the vendor uses masking or a different search process, ask them to show exactly what the cashier and guest can see at each step.
A separate live service pilot, if you choose one later, needs an approved process, trained staff and a way to handle real exceptions. Do not turn the demonstration into a live guest test just to see whether a message arrives.
Set approval, correction and escalation rules
Before signing, put the acceptance criteria in writing. The restaurant owner or assigned loyalty manager should own the rules; the vendor should demonstrate how the proposed setup supports them. Use these questions as a checklist:
- Proof: What verification methods are available when the old phone number or email is unavailable? Can the restaurant set which methods staff may accept?
- Permissions: Which roles can search profiles, view balances, change identifiers and approve an exception? What information is hidden until ownership is established?
- Conflicts: What happens when a new identifier already belongs to a profile, or when the search returns more than one plausible match?
- Record: Can the restaurant review the request date, account affected, change made, staff member, approval and reason without storing unnecessary proof details?
- Correction: If an identifier is changed on the wrong account, who can reverse or correct it, and how is the correction linked to the original action?
- Escalation: How does a cashier flag an unresolved request, and how does the manager see, resolve or close it?
Agree on what a guest is told while a request is pending. A useful response is that the team needs to review the account, not a confirmation of another person’s contact details or balance. Set a follow-up expectation your team can actually meet, and provide a route for the guest to ask about the status.
Updating contact information also does not automatically establish permission to send marketing. Ask how the system records and handles communication preferences separately from the identifier used to access an account. For broader planning, compare those requirements with your restaurant management software and the staff workflow at your restaurant POS system.
Next step: Bring the worksheet and failure case to your vendor demonstration. Compare your requirements with Fleksa’s restaurant marketing tools, and confirm current support for the recovery, permission and audit steps you need before choosing a workflow.
Frequently asked questions
Can a guest recover an account without the old phone number?
Potentially. Ask whether the vendor supports an approved alternative, such as verification through an email already on the account, and what manual review is available if the guest cannot access either contact method.
Should staff merge profiles to restore a guest’s points?
Not automatically. First verify ownership of the existing account. If there are duplicate profiles, review a separate merge process and its effect on balances and rewards before combining them.
Can a cashier update a loyalty account based on a name and old number?
Those details can help locate a record, but they do not reliably establish ownership. Require the proof and approval defined in your restaurant’s recovery rules before changing an identifier.
