To prevent an offer from appearing valid at a restaurant that does not accept it, treat location eligibility as a launch requirement, not a footnote. Maintain one list of participating locations, use it to check both the offer settings and every guest-facing description, and test what happens when a guest selects an excluded restaurant.
The offer should not invite redemption where it cannot be redeemed. If the software cannot prevent that invitation, make the limitation clear before the guest commits to an order and give staff a consistent way to handle confusion. If neither control is reliable, do not launch the offer across the affected locations.
Map the offer to each location
Start with the restaurant locations, not the campaign message. For each physical site, record its name as guests see it, the location identifier used in the software, and whether it participates. Similar names can hide different settings: “Downtown” in a campaign may not match “Main Street” in the ordering system.
Then define participation in two separate steps. Can a guest earn credit at the location? Can a guest redeem the resulting reward there? A restaurant might allow one and not the other. Also distinguish a points balance or dollar-equivalent estimate from a reward that the guest can actually select and use. A balance alone does not prove that a reward is available at a particular site.
Record the terms guests need before they act: the participating locations, what qualifies for earning, the reward they can redeem, and any other conditions that change their choice. Check those terms wherever the offer appears, including the loyalty screen, campaign copy, ordering flow, and any in-store material. A list hidden after the guest has built an order is a weak control.
Hypothetical worksheet: Assume an owner has three restaurants and wants to offer one free side after a guest earns enough eligible-order points. The owner intends to permit earning and redemption at two sites, but neither at the third. The table shows the intended rules, not a claim about any product's configuration.
| Location | Earn points? | Redeem free side? | Guest-facing instruction |
|---|---|---|---|
| Oak Street | Yes, on eligible orders | Yes, when reward is available | List as participating |
| River Road | Yes, on eligible orders | Yes, when reward is available | List as participating |
| Hill Plaza | No | No | Clearly identify as excluded |
Use the last column as an acceptance requirement, not just copy for an advertisement. If Hill Plaza is excluded, a guest choosing it should not see an unqualified “free side available here” message. If the experience cannot make the exclusion clear before the guest commits, revise the offer or hold the launch.
Ask the vendor how location rules are set, who can change them, and whether a location name or ownership change affects existing offers. Fleksa's marketing software page describes loyalty points for eligible orders and promo codes; ask how your specific location rules and guest-facing terms would be configured before relying on them.
Test earning and redemption at every site
A configuration screen shows intent. The guest journey shows whether that intent reaches the person placing the order. Before launch, ask for a safe test or demonstration environment and use fictional guest details. A simulation must not charge a real card, send a guest message, or dispatch a courier. If a step cannot be simulated safely, have the vendor demonstrate it without triggering the real action.
Run the same checks at each participating and excluded site. Record the selected location, the action, what the guest sees, and the result. Save screenshots or a short description so the person responsible for the offer can compare the outcome with the worksheet.
- Check discovery. With Oak Street selected, confirm that the offer and its terms match the intended rules. Select Hill Plaza and check whether the offer is hidden or clearly marked as unavailable there.
- Check earning. Simulate an eligible order at Oak Street and inspect the points result. Repeat at Hill Plaza; the excluded site should not award points under the hypothetical rules.
- Check redemption. Use a test account with an actually available free-side reward. Confirm that it can be selected at Oak Street and cannot be selected at Hill Plaza. A points balance that has not become a redeemable reward is not an adequate redemption test.
- Change location. Start with Oak Street, then switch to Hill Plaza before completing the simulated order. Check that the message and reward availability change with the selected location.
- Check a return visit. Reopen the offer with Hill Plaza selected. Look for saved screens or messages that still imply the reward is valid there.
The decision boundary is straightforward: launch only when participating sites accept the intended actions and excluded sites do not present the offer as usable there. An unavailable reward with clear wording may be acceptable; an apparently valid reward that fails only at the final step is not. If results differ from the worksheet, correct the setting or message and repeat the affected checks.
Also test the less obvious split if your actual offer allows earning at a site that cannot accept redemption. The guest needs to understand both facts. Ask whether the software can display that distinction at the point of choice. Do not assume a single participation switch covers both rules.
Prepare staff and resolve guest confusion
Give each location a short version of the same matrix. It should say which sites participate, whether earning and redemption differ, what the guest needs to show or select, and whom staff should contact when the screen conflicts with the written terms. Name a role responsible for updates so an old printout does not become the operating rule.
For the hypothetical offer, staff at Hill Plaza should be able to say that the free-side reward is not accepted there and identify the participating restaurants. They should not promise points or a substitute reward unless the owner has authorized that response. Decide in advance whether a manager may make an exception, who records it, and how that exception will be distinguished from a change to the promotion itself.
Give support staff a path for checking the guest's selected location and the offer terms the guest saw. A useful handoff includes the location, approximate time, description of the message, and any non-sensitive reference needed to investigate. Avoid asking staff to collect card details or unnecessary personal information in a shared note.
Ask the vendor what staff can see when a reward is rejected and whether the reason distinguishes an excluded location from an unavailable reward. Also ask how a correction reaches the people who answer guest questions. A cashier should not have to guess whether the problem is the balance, the selected restaurant, or the offer's location rules.
Location ownership matters too. If a site is operated by a different team, agree on who approves participation and who pays for a redeemed item before the campaign goes live. For the broader economics, use the loyalty reward cost guide; keep those cost decisions separate from the question of whether the guest can actually redeem at a given site.
Launch, change, and withdraw by location
Assign one owner to the master location list and one person at each restaurant to confirm readiness. Before release, compare the list against the software settings, guest-facing terms, staff instructions, and test results. A location is ready only when those pieces agree. A campaign approval should identify the version of the list it covers, so a later site change is not mistaken for the original approval.
For a location-level change, use the same sequence in reverse and then forward: document the requested change, decide when it takes effect, update the settings and guest-facing wording, brief affected staff, and repeat the relevant simulated tests. Check both the changed site and at least one unchanged site. That helps catch a broad setting change when only one restaurant was supposed to move.
Withdrawal needs an owner too. Decide how to stop showing the offer, how to handle rewards already earned, and what staff should say if a guest arrives with an older message. Ask the vendor whether a withdrawn location can still appear in previously distributed material and what controls are available for current screens. If old material can remain visible, prepare a clear explanation and support route rather than assuming every guest will see the update.
After launch, review location-related complaints and failed redemption reports, if available, against the matrix. A recurring issue at one restaurant may indicate a stale message, an incorrect setting, or a staff instruction that did not reach the shift. Correct the cause and retest; do not treat each complaint as an isolated exception.
Next, bring your location list and intended earning and redemption rules to a conversation with Fleksa. Ask the team to walk through the participating-site, excluded-site, and location-switch scenarios using a safe demonstration, and compare the workflow with your requirements before committing.
Frequently asked questions
Can a guest earn points at one location and redeem at another?
That depends on the offer rules and software configuration. Specify the intended earning and redemption locations separately, then ask the vendor to demonstrate the exact cross-location journey.
What if an excluded restaurant still receives guest complaints?
Check where guests saw the offer, whether the selected location was clear, and whether the current message matches the location list. Give staff an approved response and a way to report the mismatch for correction.
Should every location run the same loyalty promotion?
Not necessarily. Locations may have different operating agreements or willingness to fund rewards. A consistent offer can be easier to explain, but an excluded location is workable only when its exclusion is clear and the redemption controls support it.
