For a time-sensitive promotion, purchase and consent data should be current enough to reflect changes that could alter who receives the message. Set that limit before building the audience. If you cannot verify it at send time, hold the campaign.
The right limit depends on the offer. A lunch promotion excluding guests who purchased this morning may need updates within minutes. A broad announcement may tolerate older purchase data, but a recent opt-out still needs to be reflected before a marketing message goes out. Contact details alone do not establish permission to market.
The worksheet below uses one hypothetical example. Its time limits are operating choices for that example, not universal rules or claims about any product.
Map each source and its freshness limit
Start with the decision the audience must make. Suppose a restaurant plans to send an SMS offer at noon to guests who have consented to marketing and have not purchased since 8 a.m. The goal is to avoid sending an immediate return offer to someone who already bought breakfast or lunch.
The owner sets two requirements: purchase data must include eligible transactions through at least 11:55 a.m., and the final consent check must reflect opt-outs received through the point the audience is released for sending. If the system cannot check consent at release, the owner must choose another approved workflow or hold the send. A five-minute purchase limit is useful here because a recent purchase changes eligibility; it is not a substitute for the consent requirement.
List each source separately. A restaurant POS system may be one source of purchases, while an ordering system or another sales channel may hold others. Identify where SMS consent and opt-outs are recorded, and ask whether the campaign tool receives those changes directly or through another system. Include every channel covered by the offer's eligibility rule.
For each feed, record its expected update schedule, last successful update, and the latest event time actually covered by the data. Those are different things. An update that finished at 11:58 might contain transactions only through 11:45. A scheduled update is also not proof that it ran successfully.
The table translates the example into a send decision. The purchase feed is too old even though it updated recently; the consent row requires a final check rather than reliance on the earlier snapshot.
| Data and source | Example status at noon | Required result | Decision |
|---|---|---|---|
| Purchases from POS and ordering sources | Last successful update finished at 11:58; records covered through 11:45 | All relevant sources covered through at least 11:55 | Hold: coverage is 10 minutes older than the cutoff |
| SMS consent and opt-outs | Audience snapshot created at 11:50 | Final check includes opt-outs received through audience release | Hold until the final check is confirmed |
| Campaign audience | List built at 11:50 | Rebuild or recheck against qualifying data before release | Do not send the old list as-is |
Ask vendors how an operator can see the latest covered event time for each source, not just a green connection indicator. Also ask whether a failed source is visible when other sources continue updating. A single overall timestamp can hide a stale sales channel.
Simulate a purchase and an opt-out before release
A useful check follows individual changes from their source to the audience decision. Use a sandbox, preview, or other non-sending mode agreed with the vendor. The exercise must not trigger a real payment, guest message, or courier dispatch. Ask how to create fictional records and inspect the result without releasing a campaign.
For the same noon campaign, create two fictional guest records:
- Guest A: Has SMS marketing consent and makes a simulated purchase at 11:53 a.m. Expected result: excluded because the purchase falls after 8 a.m. and before the 11:55 purchase coverage cutoff.
- Guest B: Was eligible when the list was built at 11:50 a.m. but submits a simulated opt-out at 11:57 a.m. Expected result: excluded by the final consent check before release.
Observe the source record, the event time, the update or check that carries the change, and the resulting audience status. A pass requires both guests to be excluded for the right reason. Guest A disappearing because the phone number is invalid does not prove that purchase data arrived. Guest B disappearing for an unrelated audience rule does not prove the opt-out was honored.
Run the same exercise with an otherwise eligible fictional guest who has no disqualifying purchase and has consent. That record should remain eligible. This control helps expose a rule that simply removes everyone. It does not prove a real campaign will reach any particular person.
Ask whether the audience is a fixed export or is evaluated again at release. If it is fixed, find out whether it can be rebuilt and whether a separate consent suppression check runs against the rebuilt list. A preview from an hour earlier is not evidence of the final audience.
If you later choose a live service pilot, treat it as a separate operational decision with authorized participants and normal send controls. The simulated check above is not a live pilot and should not contact guests.
Match data delay to the eligibility rule
Freshness has value only in relation to a decision. A guest's purchase at 11:53 matters to the noon offer because the rule excludes purchases since 8 a.m. For an anniversary announcement that does not use purchase history, that same transaction may not change eligibility. Map each rule to the field and source that can change its result.
For the example, the five-minute purchase limit leaves a possible gap from 11:55 until noon. A purchase in that gap could still receive the offer. The owner must decide whether that exposure is acceptable before sending. If it is not, shorten the limit or require a final purchase check closer to release. Do not call the audience fully current merely because it meets a five-minute threshold.
Other rules can have different tolerances. A birthday month may be stable for the day, while a same-day redemption limit can change after every order. If an offer excludes guests who have already redeemed it, ask which system records redemption and how quickly that record becomes available to the audience check. A reward equivalent shown in a report is not proof that a guest has a reward they can actually redeem.
Check what happens to late corrections as well. A canceled transaction, a corrected guest profile, or a duplicate contact can change the decision. Ask whether the audience uses the original event time or the time a correction arrived, and how a duplicate is matched across sources. If the answer is uncertain, narrow the rule or hold the affected audience until the records can be resolved.
With restaurant management software, the buying question is not simply whether data appears on one screen. Ask which fields are available to campaign rules, how often they update, and whether staff can inspect the specific records that caused an inclusion or exclusion. Request the same demonstration for each sales channel the promotion covers.
Set a hold, an owner, and a recovery path
Write the release rule where the person scheduling the campaign can use it. For the hypothetical noon offer, the rule is: purchase coverage must reach 11:55 for every relevant source, the audience must be rebuilt or rechecked, and opt-outs must be checked through release. If any condition fails, the campaign stays on hold.
Name one person who can stop the send and one person who can investigate the feed. Agree on how they will see a failure and how long they will wait before changing the promotion. For a lunch offer, a delayed send may miss the useful window entirely. Canceling or rescheduling can be better than sending to an audience that no longer fits the offer.
Use observable criteria rather than a general instruction to check the data:
- Pass: Each purchase source shows coverage through the cutoff; the audience uses that data; the final consent check is confirmed; and the simulated records produce the expected decisions.
- Fail: A source has an unknown coverage time, a required update failed, a recent qualifying purchase remains eligible, or an opt-out remains eligible at the final check.
- Recovery: Resolve the source issue, confirm the new coverage time, and rebuild or recheck the audience. Then repeat the relevant checks before release. If the promotion window has passed, reschedule or cancel it.
Keep a short record of the planned send time, thresholds, source coverage times, exceptions, decision, and person who approved it. This makes the next campaign easier to diagnose without treating an old pass as proof that today's feeds are current.
As a next step, take one planned promotion and its eligibility rules to Fleksa. Compare your requirements with its restaurant marketing automation, and confirm current availability, update visibility, audience rechecks, and send controls before choosing a workflow.
Frequently asked questions
Is a daily data update enough for a restaurant promotion?
It depends on the rules. A daily purchase update may be too old for an offer that excludes today's buyers. Set a limit based on how quickly a change can alter eligibility, and check consent separately before release.
Does a successful sync mean the audience is current?
Not necessarily. A sync can finish recently while carrying older records, or one source can lag behind another. Check the latest event time covered by each relevant source and whether the audience uses that data.
What if the campaign tool cannot show a freshness time?
Ask how staff can verify the records included at release and how the tool handles recent purchases and opt-outs. If the required freshness cannot be established, hold the affected campaign or use a different verified workflow.
