A manager can change a POS floor plan safely during service only if the system preserves the identity of every open check and staff can still find the right guests afterward. That behavior depends on the POS, the kind of edit, permissions, and the devices in use. Ask for a demonstration with an occupied sample table before relying on it.
The important distinction is between changing the map and transferring a guest party. Renaming a section changes how staff navigate the floor plan. It should not be assumed to move a party, merge checks, or change a bill. Your evaluation needs to show what actually happens to the open check when the map changes.
Set the requirements around your service
Start with a floor plan that resembles your restaurant. Include the dining room, patio, bar, or other areas staff actually use. Note which devices display the plan and who needs to make changes: a manager at a fixed terminal, for example, or a shift lead using a handheld.
List the edits you expect to make during a shift. Renaming a section may be routine; deleting an occupied table or splitting a room into new sections may be much riskier. Ask the vendor to show each edit separately. A successful rename does not establish that a table deletion or layout replacement is safe.
Choose one person to own the decision, usually the operator or general manager. The shift manager should explain the service workflow, while a lead server and the person responsible for devices check whether the result is usable. Decide which changes need approval and which, if any, can wait until all checks are closed.
Write acceptance criteria before the demonstration. For a section rename, a reasonable starting point is:
- The manager can make the permitted change without closing the sample check.
- The check remains open and its items, total, and identifying details are unchanged.
- Staff can locate the check from the updated plan and confirm it belongs to the same sample party.
- Other in-scope devices show a consistent result after the required refresh.
- The team knows what to do if the change fails or a device shows an older layout.
Use these criteria when comparing a restaurant POS. If your operation relies on reservations or other connected workflows, ask whether a floor plan edit affects what those staff see, too. Keep that question separate from whether the open check survives.
Compare permissions, occupied tables, and devices
Give each vendor the same requirements sheet. 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 do not establish how any of the three handles an occupied-table edit.
Ask the demonstrator to use the roles you expect to assign. Can a server view the plan but not edit it? Can a shift manager rename a section? Does an administrator need to approve or publish the change? If the system cannot limit edits in the way you need, decide whether a documented manager-only procedure is enough or whether that is a deal-breaker.
Then ask what happens when an occupied table is affected. Is the check associated with a persistent table identifier, a displayed name, or something else? Can the operator find it by check number or another identifier if its location looks different? What prevents two tables with similar names from being confused?
Include the actual devices and channels that matter to your team. A result on one terminal does not establish what a handheld, another terminal, or a connected reservation view will display. Check the proposed restaurant hardware, network setup, and any device-specific refresh steps with the vendor. Record an unshown device as unknown, not as a pass.
Also ask how the system handles a change that is not allowed. A clear warning that prevents an unsafe edit may meet your needs better than a change that goes through but leaves staff unable to identify the check. Conversely, if a section cannot be renamed while a check is open, the practical workaround may be to wait until that section is clear.
Run a safe floor plan change simulation
Use a vendor-provided training environment or another isolated setup agreed with the vendor. The scenario below is hypothetical; the figures and names are for the simulation, not claims about any product.
The sample floor has two sections: Main Room and Patio. Main Room contains six physical tables, including table M4. One sample guest party is seated at M4 with one open check, identified as check 418. The sample check has two items totaling $24. Patio has four physical tables and no open checks. A physical table is a place on the plan; a guest party is the group seated there. Do not count the party as an additional table.
The test uses sample items only. The $24 is a simulated check total, not a payment, deposit, fee, or sale. No fixed, variable, or exception costs are included. Configure the simulation so it cannot send a real guest message, take a real payment, or dispatch a courier.
- Capture the starting state. The shift manager records the section name, table M4, check 418, its two items, and the $24 total. A server confirms how they would find that check on each device in scope.
- Check permissions. With the intended server role, attempt to access the edit function. Record whether access matches your policy. Then have the intended manager role make the change.
- Rename the section. Change Main Room to Front Dining. Do not transfer the sample party or close its check. Record any warning, confirmation, or publishing step.
- Find and verify the check. From the updated plan, locate M4 and open check 418. Confirm that it is still open, belongs to the sample party, and contains the same two items and $24 total. Also check that the empty tables have not been confused with M4.
- Inspect the other devices. Have the server check each in-scope device. Follow the vendor's stated refresh procedure and note whether the new section name and the same check appear. Record any device that needs a sign-out, restart, or other staff action.
- Check reversal. Ask the vendor to demonstrate the supported way to return to Main Room, then verify check 418 again. If reversal is not available or cannot be shown, record that and agree on a manual response.
For every step, write the expected result next to what was actually observed, the person's name or role, and any workaround. If the check is visible only by searching for its number rather than from the floor plan, that may preserve access, but it is not the same as meeting the stated navigation criterion. Decide whether that workaround is acceptable for a busy shift.
Do not infer that other edits are safe from this one scenario. Run separate simulations for the changes you intend to allow, particularly moving or deleting an occupied table. If the vendor cannot provide an isolated setup or cannot prevent real actions, do not perform the simulation on live guest checks.
Record the decision and handle exceptions
The following worksheet shows how a manager could classify the hypothetical scenario. These are illustrative entries, not results from a product test. Replace them with actual observations and assign a named owner before making a purchase or rollout decision.
| Requirement | Example status | Observed result or gap | Follow-up |
|---|---|---|---|
| Manager renames occupied section | Pass | Rename completes; check 418 remains open with the same items and total. | Manager records the steps for staff. |
| Server cannot edit plan | Fail | Sample server role can access the edit screen, contrary to the restaurant's policy. | POS administrator checks role settings; owner approves any exception. |
| Handheld refresh | Unknown | The intended handheld was not available for the demonstration. | Device lead retests on that model before rollout. |
| Return to prior section name | Unknown | Reversal was not demonstrated. | Manager obtains the procedure and retests with an open sample check. |
A pass means the observed result met the written criterion. A fail means it did not. Unknown means there is not enough evidence to make either call. An unknown on a device used every shift should stay open until the team has tested it; do not convert it to a pass because another device worked.
For a failure, record the service impact and the proposed response. If a stale device could lead a server to open the wrong check, the response might be to stop floor plan edits during service until the device behavior is resolved. If the only issue is that a manager must refresh a terminal, the owner may accept a written refresh procedure after staff can perform it reliably.
Set a retest date tied to the decision: before signing, before staff training, or before the first shift using the new setup. The owner should approve any exception, identify who will communicate it to staff, and state when it expires. If a vendor changes the setup or software, repeat the relevant checks rather than assuming the earlier result still applies.
When comparing quotes, ask whether training, configuration, hardware, and support needed for this workflow are included. Fleksa's plans page is the place to check its published pricing; reviewed November 2026. Request current written quotes for the actual setup, and ask vendors about contract duration and cancellation terms rather than assuming they match.
Take the scenario to a demo
Bring your own floor plan, role list, and device list to the meeting. Ask the vendor to demonstrate the occupied-table rename, refresh, and reversal with a sample check, then leave with a written list of passes, failures, and unknowns. Request a Fleksa POS demo and use the same scenario with each product you are considering.
Frequently asked questions
Is changing a floor plan the same as transferring a table?
No. A configuration change alters the layout or its labels. A transfer moves a guest party or check to another table. Test each workflow separately because success in one does not prove the other works as expected.
Should staff edit the floor plan during a busy shift?
Only allow the specific edits your team has verified and approved. If a change could make an open check difficult to identify, wait until the affected area is clear or follow an approved workaround.
What if one device still shows the old section name?
Follow the vendor's refresh procedure and verify the check on that device. If the display remains inconsistent, stop further edits and use your documented escalation process. Retest before allowing that device back into the workflow.
