One POS can support both counter and table service, but you need to verify how it handles the handoff between them. A system that takes both types of order does not necessarily let staff move an open order, its modifiers, and its payment status between a counter and a table without re-entering anything.
Before you sign, ask each vendor to demonstrate your actual service sequence on the devices and staff roles you plan to use. The result you want is straightforward: one order record that staff can find, update, and close correctly, with a clear fallback when the usual flow does not work.
Define both service flows before comparing systems
Start with what happens in your restaurant, not a feature list. At the counter, a cashier may take an order, collect payment, and give the guest a receipt or order number. For table service, a server may start an order against a physical table, send items for preparation, add another round, and collect payment later.
Then identify where those flows meet. Can a guest who ordered at the counter sit at a table? Can a server take over an open counter order? Does the kitchen need to see a new location? Decide whether you need to transfer the order itself, change its service location, or simply let another employee find it. Those are different requirements.
Write down the result each person needs at the handoff. The cashier needs to know whether the order is still open or already paid. The server needs to see the items, modifiers, and balance without typing them again. The kitchen needs an understandable preparation ticket or screen. The manager needs a report that does not count the same sale twice.
Include your physical layout. A physical table is a location; a guest party is a group of people. One table may seat one party, while a large party may occupy two tables. If you need combined tables, multiple parties at one table, or a maximum number of open checks, ask the vendor to demonstrate those arrangements and state any limits. Do not assume a floor map handles them all.
Use the same reference menu in each demo. Choose a few items with sizes, modifiers, and an unavailable option. Your aim is to see whether counter staff and servers use the same approved prices and choices, or whether someone must maintain separate menus.
Compare the workflow, not just the feature list
Toast lists restaurant POS, hardware, online ordering, payments, kitchen display systems, and integrations. Square offers restaurant point of sale and related payment and ordering tools. Fleksa offers restaurant POS connected with direct ordering, reservations, and related tools. Those descriptions are starting points, not proof that a particular transfer or reporting flow fits your restaurant.
Give each vendor the same requirements sheet and ask for a demonstration using the roles and devices in your proposed setup. A useful demo shows the state before and after an action, not just the button used to start it.
Counter order and payment
Ask the cashier to enter an item with a modifier, show the total, and demonstrate both an unpaid order and an order marked paid in a safe demonstration environment. Can another authorized employee find each order? What appears on the receipt, preparation display, or ticket? If payment is collected before seating, ask how staff can recognize that the guest owes no further balance for those items.
Table order and transfer
Ask the server to open an order at a table, add an item, and then take over the unpaid counter order. The vendor should show whether the original order is moved, linked, or recreated. Check the modifier, quantity, order status, and balance afterward. If the system cannot do this without re-entry, record that as a limitation and decide whether your team can live with it.
Also ask what happens when the table changes, the server changes, or a guest adds food after an earlier counter payment. Can staff see which items are paid and which remain due? If the demonstration requires a different workflow, have the vendor show the entire alternative rather than promising to explain it later.
Menu and reporting
Request a view of the same item at the counter and table. Compare its name, price, modifier choices, and availability with your approved menu. Ask who can make changes and whether an update affects both service flows. For migration, verify categories, modifiers, quantities, availability, and totals before staff rely on the new setup.
Finally, ask for the end-of-shift view. A manager should be able to understand counter and table activity without treating an order transfer as a second sale. Ask which reports distinguish service type, payments, and adjustments, and how the vendor recommends reconciling them. A screen that looks right during service still needs a usable record afterward.
Run a two-service workflow comparison
The following is a hypothetical demonstration, not a claim about any product. Use it as a script for every vendor. The expected results are your acceptance criteria; record actual results only after an authorized demonstration or test.
In this example, a cashier enters one sandwich for $12 and one drink for $3. The sandwich has a no-onion modifier. The item subtotal is $15; the example excludes tax, tips, and payment processing fees. The guest starts at the counter, then moves to table 4. Table 4 is one physical table assigned to this one guest party.
| Step and owner | Action | Expected result | What to record |
|---|---|---|---|
| Counter: cashier | Enter the sandwich, no onion, and drink as an unpaid order. | Order screen shows both items, the modifier, and a $15 item subtotal. | Can the cashier save and find the same open order? |
| Table: server | Assign or transfer that order to table 4 without retyping items. | Table view shows the original items, modifier, and $15 unpaid item subtotal. | Is it the same order, and is the handoff visible to both roles? |
| Table: server | Add a $4 dessert. | Order now shows three items and a $19 item subtotal; the earlier modifier remains. | Does the preparation view identify the new item and destination clearly? |
| Close: manager | Use a simulated payment to close the $19 example and review the report. | Receipt or order record shows the items and closed status; reporting counts one $19 item subtotal, not two sales. | Can the manager trace the transfer and reconcile the simulated payment? |
The table deliberately separates the screen result from the question you need answered. For example, seeing table 4 on a screen is not enough if the no-onion instruction disappeared or the cashier's original order remained open as a duplicate. Ask the vendor to navigate back to the original view and show what changed.
Run a second variation with the counter portion marked paid in the demonstration environment before the guest moves. If the guest then adds the $4 dessert, the expected remaining item balance is $4, not $19. The earlier $15 payment and the $4 balance are payment states; they are not extra sales. Ask to see how the system represents them and how staff avoid collecting the first amount twice.
Keep practice isolated from live service. Use a vendor-provided sandbox or another authorized non-live setup. Do not send a real guest message, dispatch a courier, or charge a real card. If the vendor cannot simulate a payment or preparation step, record that step as not demonstrated and ask how it can be verified safely.
Set operating rules, costs, and acceptance criteria
Turn the demonstration into a shift rule. Name the person who initiates a transfer and the person who confirms it. For example, the cashier could assign the open order to table 4, while the server checks the items and balance before adding anything. The manager should own the daily report check and resolve discrepancies.
Agree on a fallback before launch. If an order cannot be transferred, staff might leave it under its original service location and use an agreed internal identifier to find it. Whether that is workable depends on what the system displays and what your team can manage during a rush. Ask the vendor to demonstrate the fallback too; do not assume it preserves kitchen instructions or reporting.
Make the pass criteria specific: no item re-entry for the transfer you require, modifiers retained, payment status visible to the receiving role, and no duplicate sale in the report. Add your own table-capacity and staff-permission requirements. Mark each item passed, failed, or not demonstrated. A workaround is a separate decision, not an automatic pass.
Ask for a written quote that identifies the required plan, devices, payment processor, onboarding, and recurring charges. Clarify which functions depend on a particular plan or processor. Compare operational totals over the same period and list one-time hardware separately. Payment processing fees are costs; deposits are amounts paid toward an agreement; neither is the same as sales reported by the POS. Ask about contract duration, cancellation terms, support, and what happens during an outage. Consult a qualified adviser when you need help with contract, legal, or tax treatment.
For Fleksa's current plan information, consult plans and pricing; pricing details were checked in November 2026. Confirm your own setup and quote before deciding. Also check the proposed POS hardware and how it will be installed at the counter and on the floor. Fleksa's POS page describes menu and floor preparation with onboarding guidance; agree on responsibilities and a verification schedule rather than assuming an automatic migration or a particular downtime window.
After a safe simulation, use a limited live-service pilot only if you are ready to operate the setup with actual guests and normal controls. Assign a manager to monitor it, explain the fallback to staff, and reconcile actual orders and payments afterward. That is different from a practice scenario: live service creates real transactions and should not be used merely to see whether a button works.
Take the worksheet to a restaurant POS system demo. Ask the provider to run both payment variations, show the resulting reports, and document any failed or undemonstrated requirement before you choose.
Frequently asked questions
Can one POS handle counter and table service without re-entry?
It may, depending on the order flow and setup. Ask for a demonstration that moves your actual order type, including modifiers and payment status, without staff typing the items again.
What if a paid counter order moves to a table?
Staff need to see the earlier payment and any remaining balance. Demonstrate a paid counter order followed by a new table item, and check the receipt and report for duplicate charges or sales.
Should counter and table service use the same menu?
A shared reference menu can make prices and modifiers easier to check, but your service flows may need different choices. Confirm how each menu is maintained and who can change availability.
