Test loyalty across restaurant ordering channels

Restaurant loyalty points do not necessarily follow a guest through every ordering channel. A guest might earn points on a direct online order but be unable to redeem them at a kiosk, or a marketplace order might sit outside the program altogether. The answer depends on the vendor, the integrations and your setup.

Before choosing a program, check four actions separately for each path: enrollment, earning, account lookup and redemption. Then test a journey between the paths you expect guests to use. A vendor saying that it offers loyalty points is not the same as confirming that every ordering channel supports all four actions.

Map each ordering path and loyalty action

Start with the ways a guest can place an order, not just the devices in your restaurant. A staffed counter, self-service kiosk, your own online ordering site and a third-party marketplace can each pass different information to the loyalty system. Even two paths that reach the same kitchen may handle guest accounts differently.

For every path, ask whether a guest can join, earn points, find an existing account and use an available reward. Account lookup matters because earning on one device is of little use if the guest or employee cannot find the balance on another. Also ask whether a guest can see the balance before committing to an order.

The following worksheet is a starting point for a vendor comparison. Its statuses are deliberately unverified; they are not claims that any path works or fails. Make a separate copy for each vendor and replace a status only after the vendor confirms the exact setup.

Mark each action supported, unsupported or unverified. Supported should mean it works for your intended order type and configuration, not merely that an option appears in a product list. Unsupported means the vendor has confirmed the action is unavailable in that path. Leave a cell unverified when the answer is conditional or still needs a demonstration.

Split rows when the workflow differs. For example, a guest ordering at a staffed counter may identify an account personally, while a phone order requires an employee to find it. Pickup and delivery may also need separate checks. A marketplace listing deserves its own row for each service you use; do not assume that it shares loyalty data with your direct ordering system.

Fleksa describes loyalty points for eligible orders, but that description alone does not establish which channels support each action. Keep Fleksa cells unverified until you have confirmation for your configuration. Its loyalty documentation is a useful place to start the discussion.

Get the conditions behind each answer

Ask vendors to walk through the matrix using your actual ordering paths. A useful answer names the action, the channel, any required integration and what the guest or employee must do. Ask for the conditions in writing alongside the quote or contract, especially where an important workflow depends on another provider.

Use questions like these:

• Enrollment: Can a new guest join during this order, or must they register somewhere else first? What information is required, and can the order continue if they decline?
• Earning: Which orders and items are eligible? When are points added, and what happens if an order is canceled, changed or refunded?
• Lookup: How does the guest identify the account on each channel? Can staff find it without creating a duplicate, and what happens when a guest cannot access their usual identifier?
• Redemption: Can a guest choose a reward on this path before checkout? Are there minimums, excluded items or restrictions on combining offers?
• Connections: Does the workflow require a particular integration, plan or configuration? Who supports it when the order platform and loyalty provider disagree?

Check whether a balance means the same thing everywhere. Points displayed on a screen are not automatically a reward the guest can use. The program may require a minimum balance, a particular item or a conversion step before redemption. Ask the vendor to show both the balance and the actual reward choices available at checkout.

Costs also belong in the comparison, but keep them separate from capability. Request a written quote covering setup, recurring charges, transaction-related charges and any fees for integrations or support. Ask what happens to those charges if you add a kiosk or another location. A processing-fee quote alone is not the all-in cost of running the program. For reward economics, use the restaurant loyalty reward cost guide alongside the channel worksheet.

Finally, ask who can access and export guest records if you change vendors. Access to contact details is different from permission to send marketing. If you plan to promote rewards through campaigns, ask how the system handles audience selection and send controls without assuming that an account enrollment authorizes every message.

Simulate a journey across two supported channels

Hypothetical example: A restaurant wants guests to earn on its direct online site and redeem at a staffed counter. For this example only, assume the vendor has confirmed enrollment and earning online, plus account lookup and redemption at the counter. The restaurant also assumes that 10 eligible points can be exchanged for one listed reward.

In a safe demonstration environment, create a fictitious guest account and enter a simulated online order that earns 10 points under those assumed rules. Do not use a real card payment, send a guest message or dispatch a courier. Check that the account shows 10 points and that the order is recorded on the expected account.

Next, use the simulated counter workflow to find that same account. Confirm that the reward is actually offered for redemption, not merely that the balance appears. Apply one reward to a simulated eligible order and check that the balance falls from 10 points to zero. The point arithmetic is 10 earned minus 10 redeemed equals zero; whether a real program uses those rules must be confirmed separately.

Record what an employee must enter, what the guest sees and where either person can get stuck. Then simulate a cancellation or refund and ask how the balance and reward are adjusted. Test a second journey in the opposite direction only if earning at the counter and online redemption are also confirmed. Support in one direction does not prove support in the other.

A simulation checks the workflow without creating a real transaction. If it passes, plan a separate live service pilot with the vendor and staff, using ordinary operational controls and a small, clearly defined scope. Agree in advance on who watches the results, how exceptions are recorded and when to pause. A successful simulation alone does not establish that a busy shift will run without problems.

Set expectations for unsupported paths

Once the matrix is complete, decide whether the gaps fit the way your guests order. If most regulars order directly and collect at the counter, earning online and redeeming in person may be a valuable combination. If a large share of orders arrives through a marketplace and that path cannot participate, guests may see less value in the program. The right choice depends on the channels you actually need, not the number of checkmarks in a vendor presentation.

Give staff a short, accurate explanation for each confirmed gap. For example, if a vendor confirms that marketplace orders do not earn points, staff can say: “Marketplace orders do not earn points in our program. You can earn on eligible direct orders.” Use the second sentence only if direct-order earning has also been confirmed. Do not promise that staff can add missing points manually unless that process is available and authorized.

For an unverified path, the message should be different: “I can check whether this order qualifies before you place it.” Give staff a person or written reference to consult. If they cannot confirm the answer, they should not promise a reward. Keep the guest's next step clear rather than sending them between the marketplace, the restaurant and the software provider.

Review the matrix when you add a channel, change providers or alter reward rules. Update the guest-facing wording at the same time. This prevents an old sign or staff script from promising a reward that the current checkout cannot apply.

Next step: Take your completed channel matrix to Fleksa and ask the team to confirm enrollment, earning, lookup and redemption for each path you plan to use. Compare the relevant workflow and current availability through Fleksa's restaurant marketing tools.

Frequently asked questions

Do marketplace orders earn restaurant loyalty points?

They may or may not. Ask whether the specific marketplace and loyalty setup support earning, account lookup and redemption, and whether any order or item exclusions apply.

Can a guest redeem online points at the counter?

Only if the configured program supports the cross-channel journey. Confirm that staff can find the same account and apply an eligible reward, then simulate the full flow.

Is a visible points balance the same as an available reward?

No. A balance may not meet the redemption threshold or other conditions. Check which rewards the guest can actually select on each ordering path.