Servers can control when items are sent only if the POS gives them a usable hold-and-release workflow. The other half of the buying decision is visibility: a held item must remain easy to find until someone releases it, removes it, or resolves it another way.
Ask each provider to demonstrate both parts. A button labeled “hold” is not enough if a server cannot tell what is still waiting, or if a manager has no practical way to catch a forgotten course before closing a check.
The test below focuses on what dining-room staff enter, see, and release. Kitchen screen routing is a separate question; here, the important point is whether the server can confirm what was sent and what remains held.
1. Define a two-course service scenario
Use the same hypothetical order for every demonstration. A party at one physical table orders an appetizer and an entrée. The server should send the appetizer now and hold the entrée until the party is ready for its second course.
For this scenario, the appetizer is $12 and the entrée is $24. The starting food subtotal is $36. Later, the guest asks for a $2 addition to the entrée, making the food subtotal $38. These figures include only the two food items and the addition. They exclude tax, tips, payment processing, other fixed or variable operating costs, and exception costs such as a remake.
Before starting, agree on what success means. The appetizer should be identified as sent. The entrée should remain visibly unreleased. After the change, the server should be able to review the updated entrée before releasing it. Finally, the manager should be able to identify any item still on hold before the check is closed.
Run the exercise as a simulation in a training or demonstration environment. It must not create a real card payment, guest message, or courier dispatch. Ask the provider to show the relevant send and release confirmations without sending a real order to a working kitchen. If the demonstration environment cannot show a step, record that gap and arrange a safe follow-up.
Use this worksheet to keep the observations comparable. The right-hand column describes what to look for, not a promise that every system offers it.
| Step | Server action | Evidence to look for |
|---|---|---|
| Enter | Add the $12 appetizer and $24 entrée; hold the entrée. | Both items remain on the check, with the entrée clearly distinguished as unreleased. |
| Send first course | Send the appetizer while leaving the entrée held. | A clear indication of what was sent and what is still waiting. |
| Change and release | Add the $2 entrée addition, review it, then release the entrée. | The changed item is visible before release; the system then confirms its release. |
| Close the loop | Repeat with the entrée still held and inspect the check-closing workflow. | A practical way for staff or a manager to notice and resolve the outstanding item. |
Write down the actual screens and actions required, including any permissions or setup. A provider may achieve the outcome through courses, item holds, or another workflow. The labels matter less than whether your staff can use the process reliably during service.
2. Enter the order and inspect what is held
Start from a new table check. Ask the demonstrator to enter both items as a server normally would, not through a special back-office screen. Watch when the hold is applied: during item entry, after the item is added, or only when the order is ready to send.
Then ask the demonstrator to leave the check and return to it. Can a server immediately distinguish the entrée from an item already sent? Look for a readable status, not just a color that requires staff to memorize its meaning. If the distinction depends on an icon, ask what the icon means and whether it remains visible on the device your servers will use.
Have a second person open the check. A handoff is where a buried hold becomes a service problem: the first server may remember the entrée, but the next person needs to see its status without relying on memory. Ask whether staff can find held items from a table view, a check view, or a separate list, and how many actions that takes.
Also ask what happens if a server adds another item after the appetizer has been sent. Does the new item inherit a course or hold status, or must the server choose one? The answer affects training. A default can save taps, but only if staff understand it and can see the resulting status before sending.
Include the devices in the demonstration. The restaurant POS hardware you plan to use affects where staff enter orders and how easily they can read a check. Ask the provider to demonstrate on the intended device and confirm which equipment is supported for your setup.
3. Change the held entrée and release it
Now introduce the $2 addition. Ask the server to edit the held entrée, review the updated line, and release it. The important sequence is change, inspect, then send. If the change requires removing and re-entering the item, note whether the replacement is still held or needs a new hold.
Before release, check that the order shows the correct entrée, addition, and $38 food subtotal. Ask whether the server can see any other modifiers already attached to the item. A correct price alone does not prove that the preparation details are right.
Next, release only the entrée. What confirmation tells the server that the action worked? Can they distinguish a release that is complete from an action still waiting for confirmation? Ask the demonstrator to reopen the check and show the item’s status after release. If the system uses a send queue or requires an extra confirmation, include that in the written workflow.
Try one exception as a separate simulated branch: the guest changes their mind before the entrée is released. Ask how the server removes or cancels that held item, what remains visible on the check, and whether a manager’s permission is needed. Do not assume that removing an item and releasing it are interchangeable actions.
A short role-play can reveal more than a polished demonstration. Give the second person the scenario and ask them to complete the change without coaching. Note where they hesitate and whether the screen provides enough context to proceed. This is a simulated check, not a live service pilot or proof of how the team will perform on a busy night.
4. Close the loop and compare the workflow
Return to the original state with the entrée held. Before releasing it, ask the provider to show how a server or manager would find it when the party is ready to pay. Does the check show an outstanding hold? Is there a warning, a report, or another review step? Can the check still be closed with the item held, and if so, what happens to that item?
Do not require a particular warning if a different process works for your restaurant. Do require a clear answer. For example, a small dining room may accept a check-by-check review if the held status is prominent. A larger team handing tables between servers may need a broader view of outstanding items. In either case, assign responsibility: the closing server, a manager, or both should know who checks for unresolved holds.
Ask what happens when staff reopen a check or transfer a table. Does the held status remain visible to the next employee? If a manager can override a warning or close a check with a held item, ask how that action is recorded and how the team should resolve it. These are workflow questions to demonstrate, not features to assume.
Compare the results using the same requirements sheet. Toast lists restaurant POS and related tools, including hardware and kitchen display systems. Square offers restaurant point of sale and related payment and order tools. Fleksa offers a restaurant POS alongside direct ordering, reservations, and related tools. Ask each provider to demonstrate the held-item sequence rather than inferring it from a product category.
For a decision, separate essential outcomes from preferences. If your essential requirement is that another server can find an unreleased entrée and confirm its release, a system that hides the status until several screens later may not fit, even if it has fewer taps at initial entry. Record any needed configuration, staff permissions, device requirements, and training time alongside the quoted cost.
Ask for a written quote covering the setup and equipment your workflow needs. Clarify contract length, cancellation terms, processing arrangements, and what happens if connectivity is interrupted. A related guide to no-monthly-fee POS costs can help you compare the quote beyond its headline fee.
When the simulated workflow meets your requirements, plan a limited live service pilot with trained staff and the provider’s help. Use a real service workflow only after agreeing on how orders will reach the kitchen and how staff will handle an unresolved hold. Review any missed or confusing steps before making the process standard.
Next, bring the worksheet and your intended devices to a provider demonstration. Discuss your service requirements with Fleksa and ask to see the hold, change, release, and close-check steps on your proposed setup.
Frequently asked questions
What is the difference between holding and firing an item?
A held item stays unreleased for later action. Firing, or releasing, is the action intended to send it for preparation. Ask each provider how its screens label and confirm those states.
Should a POS prevent a check from closing with a held item?
That depends on your service policy. Ask whether the system blocks closure, warns staff, or relies on another review process, and decide who is responsible for resolving the item.
Can a simulated test replace a live service pilot?
No. A simulation checks the steps without real payments, guest messages, or courier dispatches. A limited live pilot helps staff assess the agreed workflow under service conditions.
