Two staff members can safely add items to the same open check only if the POS preserves both changes or gives them a clear way to resolve a conflict. Do not assume that sharing a check, or assigning it to more than one person, proves that simultaneous edits work.
Ask the vendor to demonstrate the workflow on two terminals configured like the ones your team will use. Add a different item from each terminal at nearly the same time, then compare the final check with the kitchen output. A reliable result has each intended item once, with the right details, and no unintended ticket or duplicate.
Set the requirements around a real service workflow
Start with the moment that makes concurrent entry useful. A server might take a drink order while another employee adds a late appetizer to the same party's open check. Both need to work quickly, but the kitchen and the guest still need one accurate order.
Write down who performs each action. Include the staff roles, the two terminals, the open check, and the kitchen display or printer that receives the order. Note whether staff normally save items first and send them later, or send each addition immediately. Those are different workflows and should be checked separately if the restaurant uses both.
Also define what counts as the same check. Staff may be working at the same physical table but using separate checks, or they may share one check for an entire party. This test concerns one open check with the same identifier on both terminals. It does not test split checks or determine who gets credit for a sale.
Choose items that are easy to tell apart, including any modifiers your team commonly uses. The final result should preserve the item names, quantities and modifiers, not merely show the right number of lines. Decide whether the intended kitchen output is one combined ticket or separate additions, and confirm how the proposed setup represents each item.
Before a demonstration, ask for an isolated training or test environment. The practice must not create a real payment, guest message or courier dispatch. Route kitchen output to a test display or printer, or use another isolated view that cannot be mistaken for a live order. Do not use a real guest check or card.
Compare access rules and conflict handling
Give each vendor the same requirements sheet and ask them to show the proposed configuration, not just describe general POS functions. Fleksa offers a restaurant POS connected with direct ordering, reservations and related tools. Toast lists restaurant POS, hardware, online ordering, payments, a kitchen display system and integrations. Square offers restaurant point of sale and related payment and ordering tools. Those descriptions do not establish how simultaneous check edits behave.
For each system, ask the demonstrator to open the same check under two staff logins. Can both users edit it at once? Does one user have to wait? If access is locked, who sees the lock and how is it released? A system that prevents the second edit may fit a restaurant willing to use that process, but it is not the same as accepting both edits concurrently.
If both users can enter items, ask what happens when their updates overlap. Look for a clear warning, an automatic refresh or another visible outcome. Ask whether an employee must retry and how they can tell whether the first attempt was saved before doing so. A warning is only useful if the employee can act on it without guessing.
Match the demonstration to your planned network, staff permissions, restaurant hardware and kitchen setup. Ask which devices and connections are supported in the quoted configuration. If the demonstration uses a different device or setup, repeat the check on the intended one before approving rollout.
Get a written quote for the proposed configuration and ask about contract duration, cancellation terms, payment processor choices and offline behavior. Compare the operational quote totals as well as the workflow; a successful demonstration alone does not establish the full cost or contract terms.
Run the two-terminal check and compare output
The following is a hypothetical practice scenario. A server adds one iced tea while a second employee adds one salad with dressing on the side. The expected final check contains one iced tea and one salad with that modifier. The expected kitchen output contains the salad and its modifier once; whether the drink appears there depends on the restaurant's configured routing.
- Prepare the check. In the isolated test environment, open one check and record its identifier. Sign in on both terminals using the roles that would perform the work in service. Confirm that both screens show the same starting item list.
- Enter different items. Have the first person select the iced tea and the second select the salad and modifier. Pause before the save or send action so both people are ready.
- Submit at nearly the same time. On a shared count, perform the same save or send action on both terminals. Record what each screen shows, including any lock, warning, delay or prompt to refresh. Do not assume a tap succeeded just because it was made.
- Inspect the result. Open or refresh the check as the system directs. Compare its identifier, item names, quantities and modifier with the expected list. Check the isolated kitchen output against the intended routing. Count both line items and ticket entries so a repeated send is not overlooked.
- Document the outcome. Record the configuration, staff roles, sequence of actions and what appeared on both terminals and in the kitchen view. Have a manager and the vendor demonstrator review any difference before anyone retries.
Repeat the exercise with the normal save-then-send sequence if the first run sent immediately, or vice versa. Also ask the vendor to demonstrate its recommended response when one user receives a conflict warning. Before retrying, inspect the check and test kitchen output. If an item is already present, sending it again could create the very duplicate the team is trying to avoid.
A single clean run is useful evidence, not proof that every overlap or network condition will behave the same way. Repeat the scenario enough to understand the normal workflow, and ask what happens if a terminal loses its connection during an edit. Do not assume an offline change will be accepted or paid for later.
Decide what passes and how staff recover
Use the table to classify the specific workflow you observed. A pass requires both an accurate check and the intended kitchen output. A conflict message can be acceptable if it leads to a clear recovery process and the final result still meets those requirements.
| Decision | What you observe | What to do |
|---|---|---|
| Pass | Each intended item and modifier appears once on the check; the test kitchen output matches the configured routing. Any conflict is resolved clearly. | Document the steps and train staff on the demonstrated workflow. |
| Fail | An item is lost, duplicated or changed, kitchen output is wrong, or staff cannot resolve a conflict without guessing. | Do not approve this workflow for rollout. Ask the vendor to explain and demonstrate a correction. |
| Unknown | The result cannot be verified, the intended setup was not used, or the demonstration did not cover a needed sequence. | Repeat the relevant scenario in the intended configuration and capture both check and kitchen results. |
Agree on a temporary workaround for a failed or unknown result. For example, designate one employee to enter additions on a shared check while the other communicates the items to them. The designated employee should confirm the check and kitchen output before sending further changes. This reduces simultaneous access, but it adds a handoff and may slow service; make sure the team can actually follow it.
Choose an approval owner, such as the restaurant manager responsible for service, before rollout. That person should have the requirements sheet, the recorded results for each required sequence, the vendor's explanation of any warnings, and the agreed recovery steps. If a configuration changes, repeat the affected check rather than relying on an earlier result. Keep the instructions accessible alongside the rest of your restaurant management software procedures.
Request a demo of the Fleksa restaurant POS using your two-terminal scenario. Ask the demonstrator to show the final check, isolated kitchen output and the steps staff should take if an edit conflicts.
Frequently asked questions
Does shared check ownership mean simultaneous edits are safe?
No. Ownership or attribution tells you who is associated with a check. Test concurrent entry separately to see whether both changes are preserved and sent correctly.
What if the POS locks the check for the second employee?
Confirm that the lock is visible, that staff know when it clears and that the second employee can add the item afterward. Decide whether that extra wait fits your service workflow.
Should we try this during a live shift?
Start in an isolated test environment, with no real payment, guest message or courier dispatch. Consider a supervised live service pilot only after the practice passes and the manager has approved a recovery procedure.
