To stop delivery channels from accepting orders while your restaurant is closed, give one person ownership of the schedule, record the hours shown on every channel, and confirm which system actually controls order acceptance. Then check regular closures and exceptions before they reach guests.
Do not assume that changing hours in your POS changes every marketplace. A channel may use its own schedule, an integration may pass along certain changes but not others, or a temporary pause may work differently from a holiday schedule. The practical answer is to map your exact setup and give staff a fallback for anything that does not update as expected.
Map the hours for each location and channel
Start with one restaurant location and list every place a guest can initiate an order: direct online ordering, each delivery marketplace, and any other ordering channel you use. Include pickup as well as delivery if the hours differ. Repeat the exercise for each location; a shared brand name does not mean shared schedules.
For each channel, write down the customer-facing hours, the place staff edit them, and the person who can make the change. Record the POS schedule too, even if nobody knows yet whether it controls the channel. Note the restaurant's time zone and distinguish the last accepted order from the time the kitchen or dining room closes.
The following worksheet uses a hypothetical single location in Eastern Time. Its kitchen takes delivery orders from 11 a.m. to 9 p.m. Wednesday through Monday and is normally closed Tuesday. On one upcoming Tuesday holiday, the owner wants to accept delivery orders from noon to 6 p.m. The marketplace names are placeholders, not claims about any provider.
| Schedule or channel | Regular week | Tuesday holiday | Owner and next decision |
|---|---|---|---|
| POS location schedule | Wed–Mon, 11 a.m.–9 p.m.; Tue closed | Target: noon–6 p.m. | Manager: confirm whether this schedule affects order acceptance. |
| Direct ordering | Wed–Mon, 11 a.m.–9 p.m.; Tue closed | Target: noon–6 p.m. | Manager: check the guest view and where to enter the exception. |
| Marketplace A | Wed–Mon, 11 a.m.–9 p.m.; Tue closed | Target: noon–6 p.m. | Shift lead: check whether the exception must also be entered in the marketplace. |
| Marketplace B | Wed–Mon, 11 a.m.–9 p.m.; Tue closed | Target: noon–6 p.m. | Shift lead: confirm holiday settings and who can publish them. |
The regular hours in the table are the intended schedule, not proof that every system follows it. The holiday entry is a target until the responsible person checks it. Add columns or a separate note for observed guest-facing hours, the date checked, and the result. If a marketplace has separate pickup and delivery schedules, give each its own row.
Also list temporary access needs. If only the owner can edit a marketplace account, the closing manager needs a way to reach that person when the kitchen closes early. Keep account credentials in your normal secure access process, not in a worksheet shared with the whole team.
Find out which schedule wins
Ask each provider to show how hours work for your specific location, POS and channel combination. The important question is not simply whether the systems connect. It is what happens when their schedules disagree.
For example, suppose the POS says closed while Marketplace A says open. Ask whether a guest can still submit an order, whether the order reaches the POS, and what staff see if it does not. Then reverse the conflict: the POS says open, but the marketplace says closed. A schedule that blocks an order in one direction may not resolve the other direction.
Work through these questions with the provider:
- Where are regular hours and holiday exceptions entered? Are pickup and delivery edited separately?
- Which schedule controls whether a guest can submit an order? Does a POS closure override a channel schedule, or must staff update both?
- Does an hours change take effect immediately, after a delay, or only after another action? How can staff tell it has taken effect?
- Does the system use the location's time zone? How are an overnight service and a daylight saving time change handled?
- Can staff pause ordering for an unexpected closure? Does that pause expire automatically, and who must reopen the channel?
- Can guests schedule an order for a future time during a closure or exception? What happens if the hours change after that order is placed?
Record the answer and the manual action beside each channel. If a provider cannot show the behavior, treat it as unresolved and use the channel's own controls until you have a reliable procedure. Do not confuse a screen displaying “closed” with proof that every route to order submission is blocked.
When comparing restaurant integrations, check whether the connection you need is available for your setup. Fleksa's directory distinguishes live connections from those available on request. The guide to direct POS integrations and middleware can help you compare connection approaches; schedule precedence still needs its own check.
Simulate a closure and an exceptional opening
Before relying on the worksheet, walk through two cases: an ordinary Tuesday closure and the holiday Tuesday opening. Use a simulation or a vendor-provided safe test environment. Confirm first that the exercise cannot charge a real card, send a real guest message, or dispatch a courier. Do not use private customer data.
For the regular closure, set the simulated time to Tuesday at 2 p.m. The expected result is that a guest cannot submit an immediate delivery order on any channel for the closed location. Record what each guest-facing screen shows and whether an attempt to proceed is blocked. If future ordering is offered, check the available fulfillment times separately rather than treating their presence as an immediate-order failure.
For the holiday case, enter the noon-to-6 p.m. exception using the agreed procedure. At a simulated 1 p.m., the expected result is that the channel permits an immediate order. Check again at 6:01 p.m.; the expected result is that it does not. Include any stated update delay in the procedure, and check the guest view after that delay. If a channel cannot be safely simulated, ask the provider to demonstrate the behavior instead of creating a live order.
Where a safe simulated order can pass through the integration, give it a unique test identifier and match the source order to the POS and kitchen result. Check an item modifier and the total as well as the requested fulfillment time. This confirms more than the schedule screen: it shows whether a permitted test order reached the intended destination with its details intact.
Keep expected and observed results separate. Write the simulated time, channel, schedule settings, screen result and any order-routing result. If the observed result is unknown, leave it unknown and assign someone to follow up. An unsupported exception is a documented limitation, not a failed demonstration of a feature the provider never offered.
A simulation is not a live service pilot. If you later choose to pilot a change during service, make a separate plan for real orders, staff coverage and a rollback. Do not infer that a safe simulation proves every live order will be handled correctly.
Assign owners and handle exceptions
Give one manager responsibility for the master schedule and one backup authority to act during a shift. The master schedule should say when each location accepts each order type, not just when the front door is open. The manager's job is to compare that intent with the channel settings; the integration does not replace that ownership.
For planned holidays, set an internal deadline early enough to enter the exception, allow for any update delay, and check the guest-facing view. Have the owner or manager approve the intended hours before staff publish them. After the holiday, verify that regular hours have resumed; an exception left in place can cause trouble on the next normal service day.
For an unexpected closure, give the shift lead a short checklist: pause or close each affected ordering channel using its supported controls, check the customer-facing status, notify the manager, and record when each channel was closed. If the POS closure does not control a marketplace, that marketplace remains a separate action. Decide in advance who handles any orders already accepted and how the team will communicate with affected guests through the appropriate channel.
Reopening needs a checklist too. Confirm the kitchen is ready, remove temporary pauses where appropriate, and check each guest-facing channel. A pause that expires on its own may reopen ordering before staff are ready; a pause that does not expire may leave a ready kitchen invisible to guests. Ask how each control behaves and put the answer in the worksheet.
Review the worksheet when a location changes hours, adds a channel, changes its POS or changes the person responsible for an account. A brief weekly check of the next scheduled exception is more useful than waiting for a holiday order to expose a mismatch.
Choose a setup the team can operate
The best schedule process is one your staff can follow during a busy shift. In the hypothetical worksheet, if the POS does not control either marketplace's hours, the manager should plan separate marketplace updates and checks. If a provider demonstrates that a particular connection carries the holiday exception through, the manager can remove that duplicate step for that connection—but should still verify the guest-facing result.
Ask vendors to walk through your actual channel list, regular closure, holiday exception and emergency pause. Include who can make each change and what happens when a change fails. If you are considering a restaurant POS system, ask the same questions about its role rather than assuming it is the schedule authority.
Next step: Bring your location and channel list, completed worksheet, and two test cases to a Fleksa demo. Ask which connections are available for your location and how your team would manage hours and exceptions.
Frequently asked questions
Will closing my POS stop marketplace orders?
Not necessarily. Ask the provider which schedule controls order acceptance for each marketplace and POS connection. Until that behavior is confirmed, use and check the marketplace's own closure controls.
Should holiday hours be entered on every channel?
Enter them wherever your confirmed setup requires. If an exception is supposed to flow from one system to another, allow for any update delay and check the guest-facing hours before relying on it.
How can I check hours without creating a real delivery?
Use a simulation or safe test environment that cannot charge a card, message a guest or dispatch a courier. If one is unavailable, ask the provider to demonstrate the relevant closure and opening behavior.
