For most restaurants, the practical answer is a mix: consider Ethernet for fixed stations where a cable can be installed safely, and Wi-Fi for handhelds that move around the dining room. Choose each connection around the work the station must do, not around a promise that one network is always better.
Before you buy or change a setup, map where staff take orders, accept payments, send tickets and check results. Then ask what each person should see when a connection fails. A wired terminal can still lose access if the router or internet connection fails, while a handheld may need a clear way to reconnect or move work to another station.
Start with the station and the service decision
List every device that matters during service. Include the counter terminal, handhelds, kitchen display or printer, and any office device used to check orders. For each one, note whether it stays put, who uses it and what must happen next. A cashier needs to know whether an order was accepted; a cook needs a readable ticket; a manager needs a dependable way to check the order’s status.
A fixed terminal is a strong candidate for Ethernet if there is a suitable cable route and a network port the device can use. A handheld needs mobility, so Wi-Fi is the more natural connection to evaluate. Neither choice settles every question. Ask whether the terminal, payment device and kitchen equipment use the same connection, and what happens if one device loses access while the others remain connected.
Also separate a local network problem from an internet outage. A cable may connect a terminal to the local network, but it does not provide an independent route around a failed router or internet service. Ask the vendor which functions need the local network, which need internet access and what staff will see if either is unavailable. Do not assume orders, printing or payments will continue offline.
Before signing, decide who is responsible for the network equipment, cable installation and troubleshooting. If the POS provider supports the software but another company owns the router, a manager needs to know whom to call first and how an issue gets handed over. Review the proposed POS hardware alongside your device inventory; an existing tablet, terminal or printer should not be assumed compatible.
Ask vendors to demonstrate the whole workflow
Give each vendor the same short service scenario. For example, a server enters an order on a handheld, the kitchen receives it, and the cashier checks its status at the counter. Ask the vendor to show the screen or output at each step and identify which devices and connections are involved.
Fixed terminal and handheld
For the counter, ask whether the proposed terminal connects by Ethernet, Wi-Fi or both, and what additional hardware is needed. Can the payment device connect separately, and who supports that connection? For the handheld, ask where it connects, how staff can recognize a lost connection and what they should do before entering the order again.
Make the result visible. A useful demonstration ends with staff seeing an order status, a kitchen ticket or a clear failure message—not simply a device that appears connected. Ask how a manager can check for a duplicate before an order is re-entered.
Failure, cabling and support
Ask the vendor to explain and, where practical, demonstrate three distinct cases: a handheld loses Wi-Fi, a wired terminal loses its network connection, and the router becomes unavailable. What stops in each case? What can staff safely do, and what must wait for reconnection? If a payment cannot be confirmed, staff need a clear instruction to check its status rather than charge again by guesswork.
For cabling, get a written scope covering the route, installation, network ports and any work outside the POS quote. Ask who inspects the location and who fixes a damaged cable. For support, request a contact path for service hours and a plan for diagnosing whether the fault sits with the POS, network equipment or internet provider.
Record any unavailable functions and the plan, payment processor or equipment required for the workflow shown. If a demonstration depends on a particular processor or device, put that dependency in the quote. Ask how the restaurant management software shows order and payment status after connections return.
Build a connection matrix and run a safe simulation
The following worksheet is hypothetical. It describes a small restaurant with one fixed counter terminal, two handhelds and one kitchen display. The connection choices are starting assumptions, not claims about any particular product. The restaurant must confirm device compatibility and the behavior shown in each acceptance criterion.
| Station and connection | Normal result to check | Failure and fallback | Owner and acceptance criterion |
|---|---|---|---|
| Counter terminal: Ethernet | Cashier enters an order and can see its status. | If the terminal loses its connection, manager directs staff to a working station or the restaurant’s written manual procedure. | Manager checks that the failure is visible and can identify whether the order was recorded before re-entry. |
| Two handhelds: Wi-Fi | Server enters an order and can see a clear result. | If a handheld loses Wi-Fi, server stops and asks the manager to check order status before using another station. | Shift lead checks that staff can recognize the interruption and follow the status-check step. |
| Kitchen display: connection to be confirmed | Cook sees the intended order and its items. | If no ticket appears, staff follow a written kitchen communication procedure after checking order status. | Kitchen lead confirms the expected ticket or a clear missing-ticket escalation. |
| Router: shared network equipment | Manager can identify the equipment and support contact. | If the router fails, manager uses the outage procedure; neither Ethernet nor Wi-Fi is assumed to work. | Manager can locate the contact and explain which work must pause. |
Read the matrix across, not just down the connection column. The handheld row, for example, gives the server a mobility choice and a rule for uncertainty: stop, check status, then decide whether to use another station. The kitchen row deliberately leaves the connection open until the display and installation requirements are confirmed.
For a practice run, arrange an authorized simulation with the vendor outside live service. Use a training or isolated environment that cannot send a real payment, guest message or courier dispatch. Enter a clearly marked practice order, then observe the expected screen or kitchen output. With the vendor’s guidance, simulate each relevant interruption and record what appears, who acts and whether the fallback is understandable.
Do not mark the worksheet as passed because the vendor says a function exists. Record the actual result only after an authorized check. If the safe environment cannot reproduce a router failure, leave that item open and ask how it can be verified without affecting guests or service.
A live service pilot is different from practice: it involves real operating conditions and needs a separate authorization and fallback plan. Agree in advance which staff will participate, how they will report problems and who can stop the pilot. Do not introduce a network failure during live service merely to test it.
Turn the matrix into an operating rule
Choose a primary connection and a named owner for every station. In the hypothetical restaurant, Ethernet is the starting choice for the stationary counter because a suitable cable route is assumed. Wi-Fi is the starting choice for the handhelds because servers move. If the cable route is impractical or a device lacks the required connection, revisit that choice rather than forcing the device into the plan.
Write fallbacks as actions, not labels. “Use backup” is too vague. “Ask the manager to check the order status before re-entering it at the counter” tells staff what to do and helps avoid an accidental duplicate. Decide separately how the kitchen will receive information when its normal output is unavailable, and who will reconcile manual records after service.
Compare written quotes for the complete operational setup. Separate equipment and installation charges from recurring service charges, and ask about possible exception costs such as an extra cable run or a support visit. A low device quote may leave out work needed to connect it. Keep payment processing charges separate from network and hardware costs, and ask which charges are estimates.
Before approval, resolve open questions about device compatibility, processor requirements, outage behavior and support ownership. Use a qualified installer for a site-specific cabling assessment, and consult an appropriate adviser if contract terms need interpretation. Once the setup is installed, update the matrix with the actual devices, contacts and authorized check results. Revisit it when you move a station or replace network equipment.
Bring your completed matrix to a restaurant POS system demo. Ask the provider to walk through each station, failure and acceptance criterion, then give you a written quote and a plan for safely checking any open items.
Frequently asked questions
Is Ethernet always better than Wi-Fi for a restaurant POS?
No. Ethernet is worth considering for a fixed station with a practical cable route. Wi-Fi supports mobile handhelds. The right choice also depends on device compatibility, network design and the fallback available when a connection fails.
Will a wired POS keep working if the router fails?
Do not assume it will. Ethernet connects a device to network equipment; it does not by itself bypass a failed router. Ask the provider which functions remain available and how staff can confirm order and payment status.
Can I reuse my existing POS devices?
Possibly, but confirm each device in writing. Compatibility can depend on the device, operating system, printer connection and payment processor. Include any adapters, installation and support needed when comparing the quote with replacement equipment.
