When core restaurant software becomes unavailable during service, the manager on duty should first identify what has stopped working, set a safe service limit, and tell each team how to operate. Take orders manually only if the restaurant can record, prepare, hand off, and account for them reliably. If it cannot, pause the affected channel or service.
A useful restaurant software outage runbook puts those decisions on paper before the rush. It covers the dining room, kitchen, online orders, payments, and guest communication together, rather than treating a screen failure as a problem for one station.
1. Map dependencies and keep contacts within reach
Start with the path an order follows: a guest places it, staff accept it, the kitchen receives it, someone collects payment, and the order reaches the guest. List the tools and people involved at each step. A failure in one place can leave another team working with incomplete information.
- Order entry: POS terminals, online ordering, QR ordering, kiosks, phones, and reservations.
- Kitchen communication: display screens, printers, ticket routing, and the person who confirms an order was received.
- Payment: card terminals, processing connectivity, cash supplies, and the approved procedure when a payment cannot be verified.
- Handoff: pickup shelves, delivery dispatch, table numbers, and staff responsible for checking completed orders.
- Guest communication: the phone, website notices, reservation contacts, and the person authorized to update them.
Mark which dependencies share an internet connection, local network, power supply, or vendor. If several screens stop at once, a shared dependency may be the reason. Staff do not need to diagnose the entire system before protecting service, but the map helps the manager avoid assuming that one working device means every channel is healthy.
Keep a printed contact sheet with the provider's support number, account details needed to request help, internet provider, payment processor, and internal escalation contacts. Store sensitive credentials securely rather than on the sheet. Name a primary and backup incident lead for each shift, and put the paper runbook somewhere staff can reach without signing in.
Review how your restaurant POS system connects to the rest of the order path. Ask each provider what happens to orders already submitted when a connection fails, how staff can verify their status, and whether any offline function requires advance setup. Do not assume that a card transaction can be accepted or settled offline.
2. Set manual order and payment rules
Prepare numbered paper tickets with space for the order time, dining option, table or pickup name, items, modifications, payment status, and handoff status. Use one number across the order copy and any kitchen copy. The ticket runner should read back important modifications and confirm that the kitchen has received the order.
Give each copy a purpose: one stays with the person tracking open orders, one goes to the kitchen, and one can go to the payment station if needed. Keep canceled tickets too, clearly marked, so a missing number does not become a mystery after service. Do not write full card details on paper tickets.
Decide who may accept orders and which channels must pause. A manager might keep dine-in open while stopping new online orders if there is no reliable way to see or acknowledge them. If a channel cannot be paused directly, assign someone to monitor it by whatever reliable means are available and tell guests about expected delays. If incoming orders cannot be seen at all, escalate to the provider and avoid promising that they will be fulfilled.
For payment, follow the payment provider's approved process. If card authorization is unavailable, do not mark a card order as paid merely because a guest presented a card. The manager can offer an available payment method, hold the order while checking options, or decline the transaction. Explain the limitation before the guest orders when possible. Record cash received and change given on the ticket; keep any amount due distinct from an amount actually collected.
Paper tools also need limits. Set a maximum number of open tickets the team can track, a maximum number of physical tables it can serve, and a point at which new orders stop. Those limits should reflect staffing, kitchen capacity, and the ability to communicate, not just the number of seats in the room.
3. Choose a service level and tell the team
The shift manager owns the service decision. One person calls support and records incident times; another tracks open tickets and handoffs. The kitchen lead confirms capacity, and a front-of-house lead briefs servers and hosts. In a small restaurant, one person may hold more than one role, but each task still needs an owner.
Use a short decision worksheet at the start of the outage and update it when conditions change. The example below is hypothetical. It assumes power and the phone work, but the POS and kitchen display are unavailable. Staff have paper tickets and can accept cash; card authorization and incoming online orders cannot be verified.
| Input | Current condition | Decision |
|---|---|---|
| Dining room | Eight physical tables are available; the team can track six manually. | Seat no more than six physical tables at once, regardless of party size. |
| Kitchen | The kitchen lead can handle five open paper tickets. | Pause new orders when five are open; resume when a ticket is completed or canceled. |
| Online channel | New orders cannot be reliably seen or acknowledged. | Pause the channel if possible and ask support about orders already submitted. |
| Payment | Cash is available; card authorization cannot be verified. | Offer cash before taking an order; do not record an unverified card payment as paid. |
The limits work together. Six occupied tables do not authorize a seventh, even if fewer than five tickets are open. Conversely, an empty table does not mean a new food order can enter the kitchen when five tickets are already open. A large party may produce more than one ticket; count tickets as well as physical tables.
If a second ticket runner becomes available and the kitchen lead confirms that seven open tickets can be tracked safely, the manager can raise the ticket limit to seven. That change alone does not raise the six-table limit. If the phone also fails and staff cannot coordinate reliably, the manager may instead stop seating and finish only the orders already accepted. Record the reason and time for each change.
Brief staff in plain language: what is down, which channels remain open, the current limits, who can change them, and where to bring questions. Repeat the briefing at shift changes. A host can tell guests, “Our ordering system is down. We are accepting a limited number of tables and can take cash right now.” Give an honest wait estimate only when the team can support it, and update guests if the situation changes.
For reservations or existing pickup orders, avoid promising an order is canceled, paid, or being prepared until someone verifies its status. Collect only the contact details needed to follow up, and keep the paper record in the designated secure place.
4. Restore service without losing the paper trail
A screen coming back is a signal to check, not permission to immediately reopen every channel. The incident lead should confirm with the relevant staff that orders can be entered, received by the kitchen, and tracked through handoff. Check payment status through the approved provider process. If online ordering was paused, verify who will watch incoming orders before reopening it.
Compare paper tickets with the records that appear after recovery. An order submitted before the outage may show up later, so check its number, items, guest or table reference, and status before entering it again or sending it to the kitchen. Mark each paper ticket as already present, entered after recovery, canceled, or still needing investigation. Do not discard the paper trail until the designated manager has completed the review.
Reconcile payments separately from sales. For each ticket, compare the amount due with cash actually received, verified card payments, refunds, and any remaining balance. A deposit is an amount collected toward an order, not a second sale to add on top of the full order value. If a transaction's status is unclear, flag it for investigation rather than charging again. Ask the payment provider how to resolve uncertain transactions, and consult a qualified adviser when contract, legal, or tax treatment needs clarification.
For example, a hypothetical paper ticket has $24 due. The guest gives $30 cash and receives $6 change. Record $24 collected, not $30 in sales and not a card payment. If that ticket later appears in the system, compare the entries before adding anything. This example excludes tips, fees, and taxes so the cash reconciliation is clear.
The same check applies across teams. Match kitchen copies to the open-ticket list, confirm which orders were handed off, and investigate any canceled or missing numbers. A kitchen display system may be only one part of the affected workflow; front-of-house and payment records still need their own checks.
5. Practice, review, and keep the runbook current
Run a short simulation before relying on the plan. Tell staff it is practice, use clearly marked fictional tickets, and walk through a failed POS, a kitchen handoff, and an uncertain payment. The simulation must not create a real payment, send a guest message, or dispatch a courier. Check whether staff can find the contact sheet, identify the decision owner, and apply both the table and open-ticket limits.
A live service pilot is different: it involves actual guests and orders. If you choose to pilot a controlled manual procedure during service, define its scope and stop conditions in advance, brief the team, and handle real payments and communications through approved processes. Do not create a real outage just to test the plan.
After an actual incident, hold a brief review with the people who worked it. Record when the issue started, when each channel was paused or restored, unresolved orders or payments, and decisions that caused confusion. Ask which paper fields were missing, whether limits were realistic, and whether guests received timely updates. Assign an owner and date to each fix, then replace outdated printed copies.
When comparing tools, ask vendors how staff can check order status during an interruption, what recovery support is available, and what setup an offline workflow requires. Use the guide to one platform or separate tools to map those questions across vendors. For your next step, compare your outage workflow and operating requirements with Fleksa's restaurant management software, then write the responsible person and service limits on your shift's printed runbook.
Frequently asked questions
Should a restaurant stay open during a software outage?
Only if the team can reliably accept, prepare, hand off, and account for orders within a defined capacity. Pause affected channels or service when those steps cannot be controlled.
Can staff accept card payments when the POS is down?
That depends on the payment setup and provider's approved procedures. Verify authorization and transaction status; do not assume an unavailable system can process payments offline.
What should the manager do first when software returns?
Confirm that order routing and payment checks work, then compare open paper tickets with system records before reopening channels or entering orders again.
