For a multi-location restaurant, schedule campaigns against each restaurant’s local service hours, not just the clock at headquarters. The right method depends on whether the vendor can assign each recipient to the right location, use that location’s time zone, and handle exceptions without sending at the wrong time.
Start with a location-by-location worksheet. Then compare a fixed UTC send with a local-time send and ask the vendor to demonstrate both normal dates and daylight-saving transitions. A frequency cap limits how many messages someone receives; it does not ensure a message arrives while their restaurant is open.
Map locations, service hours, and recipients
Give every participating restaurant a unique location ID, a street address, a named time zone, and the hours relevant to the campaign. Use the address and the operating schedule maintained by the operations team as inputs. Record the date those hours were confirmed: a lunch promotion needs lunch hours, which may differ from the restaurant’s full opening hours.
Use a named time zone such as America/New_York rather than a permanent offset such as UTC−5. The named zone accounts for changes in the local clock. Ask whether the scheduling tool accepts named zones and which location field controls delivery time.
Next, decide how to associate each recipient with a restaurant. A selected favorite location is one possible input; a recent order location is another. Neither necessarily reflects where the guest is right now. A person may order near work during the week and visit another location on weekends. For a location-specific offer, choose a rule that fits the offer and document it before building the audience.
Keep observed data separate from assumptions. A recorded favorite location is an observed field; assuming the guest still wants offers from it is a decision. If the field is old, missing, or conflicts with another record, decide which source wins and who can correct it. Also distinguish access to contact details from permission to send marketing messages. Include only contacts your restaurant has approved for the intended channel.
Your restaurant POS system and other order records may help identify a recent location. Ask what data can be exported, how often it is updated, and whether the campaign tool can use it without a manual reformat. Do not assume a location in one system automatically appears in another.
Compare fixed UTC with local delivery
A fixed UTC campaign sends to everyone at one absolute moment. It can be straightforward when an announcement must go out simultaneously, but the local clock will show different times across locations. Local-time scheduling aims for the same clock time in each recipient’s assigned zone; sends happen at different absolute moments.
The following worksheet is hypothetical. Assume it is a winter date when New York is UTC−5 and Los Angeles is UTC−8. Both fictional restaurants serve lunch from 11 a.m. to 3 p.m. local time. Each has 100 eligible recipients correctly assigned to that location. The campaign goal is delivery during those lunch hours, and every scheduled delivery is assumed to occur on time. These figures describe timing coverage, not opens, visits, sales, or costs.
| Scheduling choice | New York delivery | Los Angeles delivery | Recipients reached during lunch |
|---|---|---|---|
| One send at 18:00 UTC | 1 p.m. local; within lunch | 10 a.m. local; before lunch | 100 of 200 |
| 1 p.m. in each local zone | 18:00 UTC; within lunch | 21:00 UTC; within lunch | 200 of 200 |
The table shows why the choice changes the outcome: a fixed 18:00 UTC send fits New York’s lunch but reaches Los Angeles an hour before service. Under these assumptions, local-time scheduling fits the stated goal at both restaurants. It is not automatically the better choice for every campaign. If the goal were a simultaneous announcement, fixed UTC might be appropriate even though the local clock times differ.
Local-time scheduling also needs reliable assignments. If many recipients lack a usable location, a polished scheduling screen will not solve the underlying problem. Compare the number of eligible contacts with a verified location against those held for review. Decide whether that coverage is enough for the campaign before approving the send.
Ask the vendor whether one campaign can schedule by recipient location, whether separate location audiences are required, and whether staff can see the resulting local and UTC times before approval. If separate campaigns are needed, include the extra setup and review work in your decision.
Test daylight-saving changes and other exceptions
Daylight-saving transitions can create local times that do not exist or occur twice. Use a simulated demonstration rather than a live guest campaign. Create fictional locations and contacts, and configure the demonstration so it cannot send a guest message, charge a card, or dispatch a courier.
For a spring example, ask the vendor to schedule a fictional New York campaign for 2:30 a.m. on March 14, 2027. The local clock moves forward that morning, so 2:30 a.m. does not occur. For a fall example, use 1:30 a.m. on November 7, 2027, when that local time occurs twice. These hours are deliberately chosen to expose the edge case, not as recommended restaurant send times.
Before the demonstration, agree on the expected handling. For example, require the system to flag the spring time for correction and require an explicit choice between the two fall occurrences. A vendor may use a different rule; ask it to show that rule and decide whether your team can operate with it. A silent adjustment or an ambiguous scheduled time fails this particular test.
The marketing operations owner should inspect the scheduled local time, time zone, date, and UTC equivalent before accepting the result. The owner should also check that a simulated preview is not being mistaken for proof of a delivered message. Save the displayed schedule or demonstration record, note any ambiguity, and repeat the check after changing the date or location.
Run ordinary service-hour cases too. Include a restaurant that opens later than the others and one with a different lunch window. A valid local time can still be a poor campaign time if the location is closed. Ask whether the tool can prevent an out-of-hours send or whether staff must review hours manually.
Set the fallback and pass-or-fail rules
For an offer tied to a particular restaurant, a sensible default is to hold recipients with missing, invalid, or conflicting location data rather than guess their time zone. Assign the exception queue to a named marketing operations owner. That person can request a correction from the location team, select a documented alternative when appropriate, or leave the contact out of that campaign.
Set the rule before the send. For example, a brand-wide announcement may have an approved headquarters-time fallback, while a lunch offer may require a known restaurant. Do not silently substitute the recipient’s phone area code for a location: it may have no useful relationship to where the person eats.
Use this demonstration checklist with fictional records and no live sends:
- Assignment: Show which location and named time zone each fictional recipient receives, including one contact with conflicting fields. Pass if the documented priority rule is applied and the conflict is visible for review.
- Scheduling: Set a lunch campaign for 1 p.m. local at the two example locations. Pass if the preview shows 1 p.m. at each location and the corresponding UTC times for the selected date.
- Missing data: Remove one recipient’s location. Pass if that contact is held under the agreed rule, the owner can identify the exception, and no default send is silently scheduled.
- Clock changes: Enter the spring and fall transition times. Pass if the result matches the handling agreed before the demonstration and the displayed schedule makes the outcome unambiguous.
- Approval: Ask an approver to inspect the audience, location, time, and exceptions before scheduling. Pass if the team can see enough information to approve or stop the campaign using its chosen workflow.
A fail does not necessarily rule out a product. Ask whether a reliable manual workaround is available, who performs it, and how much extra review it requires. If the system cannot show the final schedule clearly or cannot keep unknown locations out of the send, treat that as a material risk for a location-specific campaign.
After the simulated checks, a live service pilot is a separate decision. If you run one, use a small, authorized audience and the normal approval process. Confirm actual delivery times against the planned local times, review exceptions, and agree on a pause procedure before expanding. A simulation alone cannot establish how a live campaign will behave.
Choose a workflow your team can maintain
Compare more than the scheduling screen. Ask who updates restaurant hours, how audience changes are handled after a campaign is scheduled, and whether the team can export a record of the planned send and exceptions. Check whether a location manager can request a change without accidentally changing every restaurant’s campaign.
For campaigns that use loyalty audiences, decide whether the audience definition still matches the location rule. A guest’s eligibility for a reward and the restaurant associated with a message are separate questions. The loyalty program guide covers the broader workflow; the immediate scheduling decision is which location clock controls the message.
Bring your worksheet and pass-or-fail cases to a vendor conversation. Compare those requirements with Fleksa’s restaurant marketing tools and confirm current support for location-based scheduling, time-zone handling, and exceptions before choosing a workflow. Also check how the campaign process fits the location records your team maintains in its restaurant management software.
Frequently asked questions
Should every restaurant receive a campaign at the same local time?
Only if the campaign goal and each location’s service hours support it. A simultaneous announcement may call for one UTC time; a meal offer usually needs a review of each restaurant’s local hours.
What should happen when a guest has no location?
For a location-specific offer, hold the contact for review unless your team has approved another rule. Name an owner for correcting or excluding the record, and make sure the fallback is visible before scheduling.
Does a successful simulation guarantee a live send will arrive on time?
No. A simulation checks the displayed logic without contacting guests. A separately approved live pilot can help the team compare actual delivery timing with the planned schedule.
