If your website loads but the ordering menu does not, replace the failed menu area with a short, honest message and a verified way to get help. Keep the rest of the site working. Tell guests that online menu ordering is temporarily unavailable, not that the entire restaurant is closed.
The best alternative depends on what staff can actually handle at that moment. A phone number may work during service; outside business hours, a current read-only menu and opening hours may be more useful. Do not present a backup order button unless someone has confirmed that it works and that the restaurant can receive those orders.
Detect the menu failure before changing the page
A blank menu is not always a failure of the whole ordering system. The page may load while a menu component stalls, an item list is incomplete, or a guest sees an error instead of categories. Your response should describe the part that is affected without making claims about systems you have not checked.
Ask your website or ordering provider how the menu failure is detected. Does the site recognize an error or a loading timeout? Can it distinguish a genuinely empty menu from one that failed to load? What happens if only some categories or item details appear? A fallback that triggers too early could hide a working menu; one that never triggers leaves guests staring at a spinner.
Set a practical threshold with the provider rather than choosing a timeout at random. Consider how long guests normally wait on a slow connection and what the system can reliably detect. If automatic detection is not available, agree on who can activate the message manually and how quickly they can do it.
Give the person responsible for the website a short set of inputs:
- Restaurant manager: current hours, the number staff can answer, and whether phone orders are being accepted.
- Kitchen lead: whether staff can handle another ordering channel and which menu information is current.
- Website or ordering provider: the symptoms, affected pages or devices, detection options, and who can change the fallback.
- Shift lead: a contact for updates and a record of when the issue was noticed.
Check at least one guest-facing page and a separate device or connection when practical. A problem limited to one browser may need a different response from a menu failure affecting every visitor. Avoid asking staff to place a real order just to confirm that a screen is broken.
Show an alternative guests can actually use
Put the message where the menu would normally appear, before guests spend time trying to reload it. Use plain language, give one primary next step, and keep essential details such as hours and location accessible elsewhere on the site.
A useful message might say: “Our online ordering menu is temporarily unavailable. Please call the restaurant to ask about ordering.” Add the number only after the shift lead confirms that someone can answer it. If phone ordering is not available, say so and direct guests to current opening hours instead.
The table below compares common fallback choices. The right option is the one your team can verify and maintain during the disruption, not necessarily the one with the most buttons.
| Fallback | Use when | Limit to make clear |
|---|---|---|
| Call the restaurant | A staffed number is working and the team can discuss orders | A call does not guarantee an item is available or that an order can be accepted |
| Read-only menu | A dated copy is current enough for guests to browse | It is not an ordering menu; prices and availability should be confirmed with staff |
| Backup ordering link | The channel has been verified and staff can receive orders through it | Do not promise the same menu, hours, fees, or fulfillment options |
| Hours and contact details | No ordering alternative is currently supported | Tell guests online menu ordering is unavailable rather than suggesting they can order there |
A read-only menu is useful for planning, but it can create confusion if it looks clickable. Label it “Menu for browsing” and identify when it was last updated. Do not use an old file simply because it is easy to publish. If staff cannot verify its contents, leave it out.
For a backup ordering channel, check the full guest journey and the staff receiving side before adding a link. Ask whether pickup and delivery are offered, whether the displayed hours are correct, and whether the restaurant is ready to fulfill orders. Remove the link if those conditions change. A working link alone does not prove an order will reach the kitchen.
Keep the fallback narrow. Reservation details, directions, and other working parts of the restaurant website can remain visible. A partial menu problem should not erase useful information or announce a full outage.
Give the shift team a clear escalation path
Decide in advance who owns the message and who contacts the provider. A small restaurant may assign both jobs to a manager; a larger operation may split them between the shift lead and whoever administers the website. Either way, staff need a name or role, not a vague instruction to “contact support.”
When an issue appears, the shift lead should note the time, affected page, device or browser, and what appeared on screen. Send a screenshot if possible, without including guest or payment information. The website owner can then ask the provider whether the issue is limited to the menu, what action is recommended, and when the next update will arrive.
Agree on an update rhythm that fits service. The provider may not have a repair time immediately, but staff should know when to check again. If a phone line becomes too busy or the kitchen stops accepting phone orders, the shift lead should tell the website owner to change the fallback rather than leave a misleading instruction online.
Hypothetical example: A restaurant's home page and hours load normally, but the ordering area shows a blank panel. The manager confirms the restaurant phone is staffed and the kitchen can take phone orders. The website owner activates a message saying the online menu is unavailable and asks guests to call. The manager sends the provider the affected page, time, and a screenshot, then checks with the kitchen during service.
If the phone line later becomes overloaded, the manager changes the message to say phone ordering is temporarily unavailable and keeps the hours visible. This example does not establish that any particular website can activate a fallback automatically. Before buying, ask how the message is published, who has access, and how quickly it can be changed.
Test the fallback and restore the menu carefully
Practice before a busy service. Ask the provider for a staging environment or another safe way to simulate a failed menu. Confirm that the fallback appears in the menu area, that its wording is readable on a phone, and that its contact details match the restaurant's current information. The simulation should not make a real payment, send a guest message, or dispatch a courier.
A simulation checks the page and the team's response; it does not prove the live ordering path works. Separately, agree with the provider on a controlled live service pilot if you need to check real order receipt. Define who participates, what is authorized, and how the restaurant will recognize and handle a pilot order. Do not create a real card payment, guest message, or courier dispatch as part of the practice simulation.
Use this checklist during an actual partial failure and again when service returns:
- Confirm the scope. Check whether the menu is affected while the rest of the site remains usable. Record what staff can observe.
- Choose the fallback. Select only an alternative the shift team can support now. Publish a short message in the failed menu area.
- Notify the owner. Send the website owner and provider the symptoms, time, and affected page. Agree on the next update.
- Recheck the alternative. Confirm that the phone is staffed or the backup channel is still being monitored. Change the message if circumstances change.
- Check restoration. With the provider, verify that categories and item details load on a guest-facing device. Use an agreed safe check for the receiving side; a visible menu alone is not proof that orders reach staff.
- Remove the fallback. Once the agreed checks pass, restore the normal menu display. Tell the shift team and note the time and any remaining issue.
If the menu reappears but the receiving side cannot be confirmed, keep a truthful message in place while the team investigates. Afterward, review whether guests had a useful next step and whether staff knew who could change it. Adjust the plan before the next disruption.
Use the online ordering buying guide to prepare provider questions, and compare the operational trade-offs in this related buying guide. Then use the checklist to evaluate your current setup and ask Fleksa about restaurant online ordering, including verified US availability and fallback options for your location.
Frequently asked questions
Should a failed menu make the whole website show an outage message?
Not if the rest of the site works. Explain that the online ordering menu is unavailable and leave working information, such as hours and directions, accessible.
Can a PDF menu replace the ordering menu?
It can be a browsing alternative if staff can verify that it is current. Label it as read-only and ask guests to confirm prices and availability with the restaurant.
When should the fallback come down?
Remove it after the menu loads correctly and the team has completed its agreed check of the order-receiving path. A visible menu by itself does not confirm that staff can receive orders.
