Yes, a POS may let staff save an incomplete order without sending it, but the important buying question is whether everyone can tell what happened next. An order that looks saved to a server but appears in the kitchen as an active ticket creates a different problem from an order that never reaches the kitchen at all.
Ask each vendor to demonstrate the complete path: save an incomplete order, leave the session, recover it on another device, review its items, and deliberately send it. Then check what staff see before payment and handover. A system is a good fit only if those states are clear enough for your team to use during service.
This decision affects servers, counter staff, kitchen staff and managers. The server needs to know what remains unfinished. The kitchen needs to know what to prepare. The person taking payment needs to know what is on the bill and whether the order still needs action.
Separate saved, sent and paid
Start by agreeing on the words your team will use. Vendors may use different labels, so ask what each label means rather than assuming that a familiar word has the same behavior on every system.
- Saved or held: The order or some of its items have been retained for later work. Ask whether that action sends anything to a kitchen screen or printer.
- Sent: An intentional action has made the relevant items available for preparation. Ask which items were sent, where they appear and how staff can confirm it.
- Paid: A payment has been recorded against an amount. Payment status alone does not establish that every item was sent or prepared.
These states can overlap. An order might contain some sent items and some newly added items that have not been sent. It may also be paid while an item still needs attention, depending on the workflow. Ask the vendor to show those combinations rather than treating an order as having one simple status.
Also distinguish an incomplete order from course firing. The question here is whether an item has been sent at all, not when an already communicated course should be prepared. If your team uses both workflows, ask how the screen makes the distinction visible.
Before comparing systems, write down the outcome you need. For example: “A server can leave an unfinished order, another authorized staff member can find it, and neither person has to guess which items reached the kitchen.” Add who may edit, send, void or take payment. Permissions and recovery behavior should be demonstrated for the roles you actually use.
Run a safe device-change and recovery test
Use a vendor demonstration or training environment with simulated orders only. Confirm beforehand that the exercise cannot create a real payment, guest message or courier dispatch. Use a simulated kitchen destination or a clearly isolated training display. Do not enter a real customer's information.
Hypothetical scenario: A server starts a dine-in order for party Harbor: one soup and two sandwiches. One sandwich still needs a modifier. The server saves the order before completing that choice. Use these same three items throughout the test so the evidence is easy to compare.
- Record the order identifier, the device and staff role. Note the visible status of each item before saving.
- Save or hold the order. Check whether the order and its items have a clear unsent indicator. Inspect the simulated kitchen destination for any ticket or item.
- Exit the session in the normal way. Sign in on a second device as a staff member who would be allowed to take over. Find and reopen the order.
- Check the quantities, the unfinished modifier and the status of each item. Then return to the first device and check whether its view agrees.
- Complete the modifier and deliberately send the items. Check the simulated kitchen destination and the POS order view. Record what changed and who performed the action.
Ask what happens if the first session closes unexpectedly, a device loses connection, or two authorized staff members open the same order. A normal sign-out does not prove recovery after an interruption. Have the vendor demonstrate each situation your operation considers important, using the same isolated test setup.
Keep screenshots or a written log of the order view and simulated kitchen view at each step. Note the device, role, action and time. Compare the views: did the soup and both sandwiches remain unsent until the deliberate send? Did the modifier survive the device change? A verbal “yes” is less useful than a record showing the state before and after the action.
Ask the vendor for written documentation of the demonstrated behavior and any setup it depends on. If the documentation and demonstration differ, resolve that difference before selecting the system. For general questions to bring to a demo, see Fleksa's POS questions.
Check item status at payment and handover
Next, repeat the Harbor scenario with a split state: deliberately send the soup and one sandwich, then add the second sandwich without sending it. The person taking over should be able to identify the unsent sandwich without relying on the original server's memory.
Ask the vendor to show what the next staff member sees on the order screen, on the simulated kitchen destination and in the payment flow. Can that person distinguish the two sent items from the one unsent item? Is the warning, if any, visible before a payment action? Can the staff member review the missing modifier and send the item from their own role?
Use a simulated payment or a vendor-provided demonstration of the payment screen. Do not run a real card charge. If the system permits a simulated paid status, check whether the unsent item remains clearly identifiable afterward. If it cannot simulate that status, ask the vendor to document the behavior instead of assuming payment will trigger a send.
For a price check in this hypothetical order, suppose the soup is $6 and each sandwich is $9. The three items total $24 before any additional charges. This is an item-subtotal check, not an operating-cost comparison: fixed costs, variable operating costs and exception costs are excluded, as are payment fees and any other charges. The $24 subtotal does not prove the kitchen received $24 worth of items.
An exception can change the buying decision. Suppose the second sandwich appears on the bill but the replacement server cannot tell that it is unsent. If handovers are common at your restaurant, that ambiguity fails the stated requirement even if the total is correct. Ask whether another screen, permission or documented workflow makes the distinction clear. If not, assess another system against the same scenario.
Finish by simulating a staff handover. The first server states the order identifier and the remaining action; the second independently locates the order and names the unsent item. If the second person needs a verbal warning to discover the state, decide whether that is an acceptable control for your service.
Assign an owner to every state change
A useful checklist names the person responsible for the next action, not just the software status. Adapt the roles below to your shifts. The evidence column gives you a way to compare the same order across demonstrations.
| Transition | Owner | Evidence to compare | Decision question |
|---|---|---|---|
| Start to saved, unsent | Order-taking server | Order view after saving; simulated kitchen view | Are retained items visible without appearing as sent? |
| Saved to recovered | Replacement server | Reopened order on second device; item and modifier details | Can an authorized person find the same unfinished work? |
| Unsent to sent | Server completing the order | Item status before and after send; simulated kitchen view | Is the deliberate send visible in both places? |
| Order reviewed before payment | Payment-taking staff member | Item statuses and simulated payment screen | Can staff identify any item still needing action? |
| Shift handover or exception | Shift manager | Order identifier, outstanding action and receiving staff member | Is there a clear owner if recovery or status is uncertain? |
The table is a comparison tool, not a claim that every POS uses these exact states. For each demonstration, mark whether the evidence meets your requirement, needs a written follow-up, or does not meet it. Keep the sample order and staff roles consistent so differences in results are meaningful.
Set a rule for unresolved orders during service. For example, the shift manager can review the order with the kitchen before anyone resends an item. That avoids assuming that an unclear screen means nothing was received. Ask the vendor how its audit history, item status and permissions can support that check; do not assume a particular history or alert exists.
When comparing a restaurant POS system, include device requirements, permissions, recovery behavior and any required setup in your written requirements. If you also use restaurant management software, ask where the order status is visible to each role. Review written quotes and contract terms separately, and ask a qualified adviser about legal or tax treatment when needed.
Next step: Request a Fleksa POS demo using the Harbor sample scenario. Ask the vendor to document the saved, recovered, sent and payment-review outcomes, including any setup or role restrictions, before you decide.
Frequently asked questions
Does saving an order mean it has been sent to the kitchen?
Not necessarily. Ask the vendor to demonstrate what saving does and compare the order screen with an isolated kitchen view before any deliberate send.
Can another server recover an unsent order?
That depends on the system, configuration and staff permissions. Test recovery on a second device with the role a replacement server would use, including any unfinished modifiers.
Does payment prove every item was sent?
No. A payment records an amount; it does not by itself establish an item's kitchen status. Review item-level status before payment and ask how the system handles any unsent item.
