For most restaurants, the practical starting point is to accept a phone number and offer a second lookup method, such as a member code or email address, when the phone number cannot identify one account confidently. Choose the combination your guests can provide and your staff can check quickly. Before committing, confirm that the system supports your chosen methods and lets staff stop a redemption when a match is uncertain.
Finding an account and authorizing a reward are separate steps. A familiar number can bring up a record, but it may belong to a household rather than one person. Your process needs to tell the cashier what to do before a reward is applied to the wrong account.
Set the lookup rules before choosing software
The owner or general manager should make the final decision with input from whoever runs the register. The manager knows what happens during a rush; the owner is responsible for the reward policy and the cost of correcting mistakes. Write the rules down so that a new cashier does not have to invent them at the counter.
Start with three decisions: which identifiers staff may enter, what staff can see after a search, and when a manager must step in. A lookup result should give the cashier enough information to distinguish accounts without exposing more guest information than the task requires. Ask the vendor what can be masked, what appears on the register and whether access can be limited by role.
Also decide what happens when the guest cannot provide an accepted identifier. The cashier might complete the purchase without a reward and explain the restaurant's follow-up process, rather than guessing. Set out who can review the account later and whether a reward can be applied after a sale. Confirm that the software supports whatever policy you choose.
Account lookup is not permission to send marketing messages. If a guest provides a phone number to find a reward, treat the separate question of marketing consent according to your restaurant's policies. Ask how contact details and marketing preferences are displayed and controlled.
Compare phone, email and member code
The table is a starting worksheet, not a promise that any product supports all three methods. Speed depends on how guests receive an identifier, how staff enter it and what the screen shows after a search. A short live demonstration with your own workflow is more useful than a feature name on a sales page.
| Method | Speed at the counter | Privacy and mistaken-match risk | Best question to ask |
|---|---|---|---|
| Phone number | Often easy to say or type; can slow down when numbers are shared or entered incorrectly. | Nearby guests may overhear it. A shared number may return more than one account or point to a different person. | What happens when several accounts use the same number? |
| Email address | Can take longer to spell or type, especially in a noisy room. | Full addresses can expose contact details on screen. Similar spellings and old addresses can lead to errors or no result. | Can staff distinguish similar addresses without displaying unnecessary details? |
| Member code | Can be quick if the guest has it ready; slower if they must find it. | A code entered incorrectly may match another account. A code shown on a screen can also be seen by others. | How is a code issued, entered and checked before a reward is applied? |
Phone lookup suits a counter where guests prefer not to open an app or search their inbox. It is less suitable as the only method when family members share a number or guests do not want to say it aloud. Ask whether guests can enter it themselves and what the employee sees afterward.
Email can help distinguish people who share a phone number, but spelling introduces friction. Ask whether the system requires an exact match and how it handles an address that has changed. Do not assume an email address is a reliable second check if the guest cannot remember which one they used.
A member code can reduce the need to say contact details aloud, provided guests can access it easily. It is still an identifier, not automatically proof that the person holding it should use every reward on the account. Ask whether a code can be shared, whether it expires or changes, and what staff should do when it appears to identify the wrong person.
If your restaurant serves regulars at a busy counter, a reasonable policy is phone first, with a member code as an alternative if the vendor offers both. If guests commonly share numbers and rarely have codes ready, email may be the better alternative. Choose based on how guests actually order, not on the number of fields a system advertises.
Use a worksheet for difficult matches
The following examples are hypothetical. They describe desired behavior for a restaurant's evaluation, not features of a particular product. Run them with fictional accounts in a vendor demo or other isolated practice environment. Do not send a real guest message, take a card payment or dispatch a courier. Stop before any live reward is redeemed.
Shared phone number
Suppose two fictional members, Maya and Luis, use the same household phone number. Maya asks to use a reward. The cashier enters the number and sees two possible accounts.
- Expected result: The system must not silently select one account and apply its reward. It should let the cashier pause and follow the restaurant's agreed way to distinguish the members.
- Cashier's next action: Ask for the approved alternative identifier, such as Maya's member code, if that method is available. Compare the result using only the details needed for the decision.
- Manager's next action: If the alternative does not resolve the match, take over. Follow the documented recovery process or complete the sale without the reward, according to the restaurant's policy.
During the demo, also ask what happens if the search returns only one record even though the number is shared. Can the employee tell there may be another account? If not, decide whether that limitation makes phone alone too risky for your policy.
Identifier entered incorrectly
Now suppose the cashier enters Maya's member code with one character wrong. Try both outcomes in the practice environment: the incorrect code returns no account, and it matches a different fictional member.
- Expected result: A no-match result should not invite staff to guess repeatedly or create a duplicate account just to finish the sale. A different match should not lead straight to redemption without the restaurant's confirmation step.
- Cashier's next action: Re-enter the identifier once with the guest's help, then use the approved alternative or call the manager if the result is still uncertain.
- Manager's next action: Check the available account details under the restaurant's policy and decide whether to proceed or defer the reward. Record the issue through the agreed support route if the account cannot be resolved.
These examples test the decision at the counter, not the whole economics of a loyalty program. Separately, decide which rewards guests can actually redeem and what each redemption costs. The loyalty reward cost guide can help with that calculation.
Set a pass or fail test for the vendor
Give each vendor the same fictional scenarios and the same rules. Ask a cashier or shift lead to operate the demo while a manager observes. Agree on the expected result before the demonstration, then record what happened and who could take the next action.
- Accepted identifiers: Pass if staff can use the lookup methods you selected and understand which one is being entered. Fail if your required alternative is unavailable or depends on an unplanned workaround.
- Shared number: Pass if the employee can stop before an uncertain reward is applied and follow your approved distinction process. Fail if the workflow applies a reward to an account without the confirmation your policy requires.
- Incorrect entry: Pass if staff can recognize a no-match or unexpected match and stop the process. Fail if the workflow makes an incorrect match look ready for redemption without your required check.
- Manual recovery: Pass if the manager can follow a documented path when neither identifier resolves the account. Fail if staff are left to choose an account or promise a correction they cannot make.
- Access and visibility: Pass if the information shown and the permissions available fit your policy. Fail if staff must expose or access more account information than your process allows.
For each failure, ask whether configuration, a different workflow or a product change would resolve it, and get the answer in writing. Ask support how an unresolved account is reported, what information to include, who can submit the request and what response time is offered. Do not treat a verbal assurance as a substitute for a working counter procedure.
After the simulated checks, consider a limited live service pilot only if the setup and staff instructions are ready. Use the approved process with consenting participating guests, monitor exceptions and stop if staff cannot distinguish accounts confidently. A live pilot is different from the fictional practice above: any actual transaction or reward must follow your normal operating controls.
When comparing systems, include the lookup workflow in the wider register decision. Ask how it fits your restaurant POS system, who can access guest records and how staff move from an account match to an eligible reward.
Next step: Take your chosen identifiers and the two scenarios to a vendor demonstration. Compare your requirements with Fleksa's restaurant marketing tools, and confirm whether the lookup methods, permissions and exception process you need are available for your setup.
Frequently asked questions
Is a phone number enough to claim a loyalty reward?
It may be enough for a clear match under your policy, but shared numbers and entry errors make it a weak sole method for some restaurants. Provide an alternative and a way to pause when staff are unsure.
Should staff accept an email address instead?
Email can be a useful alternative if guests know which address they registered and the system supports the lookup. Check typing speed, screen visibility and how staff handle similar or outdated addresses.
Does a member code prove who owns an account?
Not necessarily. A code can identify a record, but it may be shared or entered incorrectly. Decide what confirmation is needed before redemption and test that step with the vendor.
