Give routine staff only the kiosk access they need to keep service moving. Let a shift manager handle approved operating changes and a controlled exit from the ordering screen. Reserve device setup, account administration and recovery authority for the owner or a specifically designated administrator.
That is a starting rule, not a setting every system offers. Before buying, check whether the kiosk software, device operating system and connected POS can enforce those boundaries separately. If they cannot, decide whether the workaround is acceptable before putting the device on the floor.
Separate device setup, menu control and service tasks
A guest-facing ordering screen can sit on top of several layers. The kiosk app displays the menu. A POS or other back-office system may control products and prices. The device itself has operating-system settings, network access and potentially other apps. Leaving the ordering screen may expose one or more of those layers.
Start by listing actual tasks rather than job titles. For example, someone may need to restart an unresponsive kiosk, but that does not automatically mean they need permission to change network settings. Someone else may be trusted to mark a menu item unavailable without being allowed to change its price.
Group tasks into three buckets:
- Device setup: install or remove software, connect the device to a network, change operating-system settings and manage device-level credentials.
- Menu and ordering control: change items, prices, availability, modifiers or the way orders reach the rest of the operation.
- Service continuity: check whether the ordering screen is working, restart it through an approved process and move guests to a staffed register when it is unavailable.
These are different permissions even when one screen appears to contain them all. Ask which system owns each setting and whether a change affects one kiosk, every kiosk at the location or other ordering channels. Review the kiosk documentation alongside a demonstration of the exact setup you are considering.
Hypothetical example: A counter-service restaurant has two kiosks, a staffed register, shift managers and one owner. The owner wants staff to keep guests moving but does not want routine employees changing prices or reaching device settings. The matrix below is the restaurant's desired policy, not a claim that a particular product supports these controls.
Assign the minimum role needed for each task
The table gives each task to the lowest role the hypothetical restaurant is willing to authorize. A higher role can supervise or take over when needed. “Controlled exit” means an approved way to leave the guest screen; it does not mean unrestricted access to the rest of the device.
| Task | Minimum role | Boundary or condition |
|---|---|---|
| Observe the kiosk and direct guests to the register | Staff | No settings access needed |
| Use an approved restart procedure | Staff | Only if it does not expose protected settings |
| Leave the ordering screen | Shift manager | Only for a defined service or troubleshooting need |
| Mark an item unavailable | Shift manager | Only if availability can be separated from price changes |
| Change a price or ordering configuration | Owner | Review affected kiosks and other ordering channels |
| Install software or change network settings | Owner or designated administrator | Use device-level access, not a shared service login |
| Grant, revoke or recover admin access | Owner or designated administrator | Keep recovery instructions away from the guest area |
The decision is to give the manager enough authority to handle a common service interruption while keeping price, device and account changes with the owner. The restaurant also needs an owner-designated backup for an absence. If the product cannot separate availability from pricing, the owner must either retain both permissions or explicitly accept the broader manager access.
Apply the same reasoning to an exit control. Ask whether a manager can return the kiosk to ordering mode without gaining access to unrelated apps, stored credentials or operating-system settings. If exiting exposes all of those, restrict the exit credential to the administrator or use another documented control. A sign telling staff not to change settings is not the same as a technical restriction.
Use individual accounts or credentials where the system supports them. A shared manager code may be easy during a rush, but it makes it harder to identify who made a change and harder to remove access for one departing employee. If shared access is unavoidable, decide who can hold the code, when it must be changed and who is responsible for distributing the replacement securely.
Document the decision in a short role list that managers can find away from the kiosk. Include the task, the authorized role, the system where the task happens and the escalation contact. Review it whenever responsibilities or software change.
Practice a handover and a forgotten credential
Plan a manager handover before a busy shift exposes a gap. The outgoing manager should report whether both kiosks are available, whether any menu item has been taken off sale and whether an unresolved device issue needs attention. The incoming manager should know how to reach the approved troubleshooting procedure and who can authorize a settings change.
Use a simulation first. With a demonstration device or a safe practice environment, walk through the steps using fictitious staff names and a fictitious menu item. Do not place a real order, take a card payment, send a guest message or dispatch a courier. Ask the vendor how to prevent those actions before practicing; if that cannot be assured, use a verbal walkthrough instead.
For the hypothetical restaurant, the incoming manager encounters a kiosk that needs a restart. The expected result is that the manager follows the approved restart route, confirms the guest screen is back and directs guests to the register if it is not. The manager should not need to change a price or install an app. Record where the walkthrough required a broader credential than the policy intended.
Then simulate a forgotten credential. The manager tells the owner rather than borrowing another employee's login or using a note taped to the device. The owner follows the vendor's recovery process, verifies the request through the restaurant's chosen procedure and restores only the access that role needs. The staffed register remains the fallback while access is being recovered.
Finally, discuss what happens if the owner cannot be reached. Name a backup administrator and keep that person's contact details available to managers. Confirm whether recovery depends on an email account, device, vendor support or another person, and who controls each dependency. Avoid storing recovery codes on the kiosk or in a shared guest-facing area.
A simulation checks the procedure without affecting guests. A live service pilot is a separate decision: if the restaurant chooses one, use authorized staff, an agreed fallback and ordinary service controls. Do not treat a simulated result as proof that the process will work under rush conditions.
Ask how access is revoked, recorded and supported
Bring the matrix to the vendor demonstration and ask to see the relevant workflow, rather than assuming a role name means the same thing in every system. Cover these questions for both the kiosk app and any connected restaurant POS system:
- Can a manager leave the ordering screen without gaining device administration rights? What can they reach after exiting?
- Can item availability, prices and other menu settings be assigned separately? Which channels or devices receive a change?
- Can staff have individual credentials? What happens to an active session when an account is removed or a role changes?
- How is access revoked on a lost or replaced device? Does the device need a connection before revocation takes effect?
- Are changes and access attempts recorded? Who can view the history, what does it show and how long is it retained?
- How does credential recovery work when the owner is unavailable, and what can support do without broadening access?
- Which setup, support or replacement costs belong in the quote, and which work remains the restaurant's responsibility?
Ask for the answers to be reflected in the proposed configuration and operating instructions. A log is useful only if it identifies an action clearly enough for someone to review it. Revocation is useful only if the restaurant knows which accounts and devices need updating when a person leaves.
If the desired controls are not available, choose deliberately among a narrower workflow, a trusted administrator handling more tasks, or another configuration. Include the cost of any additional setup or support in the operating quote; do not compare a software subscription alone with the full work of keeping the kiosk secure and usable.
Next, take your completed role matrix to a Fleksa restaurant kiosk discussion. Ask Fleksa to compare the workflow and current availability with your device, POS and recovery requirements, and identify any permissions your team would need to handle outside the kiosk software.
Frequently asked questions
Should every employee be able to leave the kiosk ordering screen?
Usually, no. Limit exit access to people who need it for an approved task, and check what the exit exposes. Staff can still direct guests to a register without holding an administrator credential.
Can a shift manager change kiosk menu availability?
That depends on the product and configuration. Ask whether availability can be assigned separately from price and menu editing, and which ordering channels the change affects.
What should happen when a manager forgets a credential?
Use the documented recovery process through the owner or designated backup. Keep service moving through a staffed fallback, and avoid borrowing credentials or exposing recovery information at the kiosk.
