Most restaurant teams should let servers enter and adjust ordinary orders, while requiring a shift lead or manager to approve refunds, unusually large discounts, and changes to payment or account settings. Report access should match the employee’s responsibilities rather than come automatically with a job title.
The right split depends on your service. A shift lead may need enough authority to resolve a guest problem without finding the owner. The key is to decide the limits in advance, give each person an individual login, and check that the POS actually enforces those limits.
Separate routine work from sensitive actions
Start with what happens during a normal shift. A server may need to open a check, add items and modifiers, move an order to another table, and close an approved payment. Restricting every correction can slow service and create a line at the manager’s station.
Then list actions that change money, records, or access. These deserve a separate decision:
- Refunds and voids: Who can reverse a completed payment, void an item, or cancel a whole check? Consider whether an unsubmitted item should be treated differently from one already sent to the kitchen.
- Discounts and comps: Can staff apply a standard offer, or also create a custom discount? Decide whether approval depends on the amount or reason.
- Closed checks: Who can reopen or edit a completed transaction, and what information remains visible afterward?
- Reports: Does an employee need their own shift totals, or access to restaurant-wide sales and employee-level results?
- Setup and access: Who can change prices, payment settings, roles, or employee accounts?
Ask the vendor how finely these actions can be separated. A single permission called “manage orders” may cover several actions you want to treat differently. If a POS cannot make the distinction, decide whether a different workflow provides enough control without holding up service.
Also look beyond the register. If your restaurant management software has separate accounts or administrative areas, ask whether staff access is managed in one place or must be updated in each tool.
Build a role-by-action matrix
The following matrix is a hypothetical starting point for a full-service restaurant. It is a policy to check against a product, not a claim about any POS. “Approve” means the named role authorizes the action with its own login; it does not mean another employee borrows that login.
| Action | Server | Shift lead | Manager |
|---|---|---|---|
| Enter orders and correct an unsubmitted item | Allowed | Allowed | Allowed |
| Void an item already sent to the kitchen | Request approval | Approve | Approve |
| Apply a standard, preapproved discount | Allowed | Allowed | Allowed |
| Issue a refund or create a custom discount | Request approval | Request manager approval | Approve |
| View restaurant-wide reports | No access | Shift reports only | Allowed |
| Change roles or payment settings | No access | No access | Allowed |
The table gives the shift lead authority over a common service correction but keeps refunds and custom discounts with the manager. That split makes sense only if a manager is reachable during the shift. If one is not, consider giving a trained lead a defined refund limit, provided the POS can enforce it and the restaurant is comfortable reviewing those transactions.
Write down details that do not fit neatly in a cell. For example, can a server remove an item before it is sent, but not afterward? Can a lead see a shift report without seeing reports for every employee? Does approval apply to one transaction or remain active for the rest of the session?
Use roles as a starting point, then review individual exceptions. A newly promoted lead may need a temporary training arrangement. An owner who rarely works service may need reporting access but not a shared manager account on the floor. Keep a short record of who approved each exception and when it should be reviewed.
Demo an exception without sharing a login
Bring the matrix to each restaurant POS demo. Ask the vendor to show the workflow using distinct server and manager accounts, with the permissions configured as they would be for your team. A verbal assurance that roles are “customizable” does not tell you what happens at the counter.
Use this simulated scenario: a server needs to void an item already sent to the kitchen. Run it in a demonstration or training environment that will not send a real kitchen ticket, charge a card, message a guest, or dispatch a courier.
- Sign in as the server, create a sample order, and simulate sending the item to the kitchen.
- Try to void the item. The expected result under the matrix is that the server cannot complete the void alone.
- Have the manager or authorized lead approve using their own credentials. Ask whether approval is tied to that one action and whether the server can continue working afterward.
- Open the transaction history or available report. Look for the original item, the void, the employee who initiated it, the approver, and any recorded reason or time.
- Sign in as the server again and try a refund and a restaurant-wide report. Both should be restricted under the sample policy.
If the product allows the server to finish a restricted action, or if approval leaves the manager account open, ask how to change the setup. If the record does not identify both people, decide whether the available history gives you enough information to review the exception.
Repeat the check on the devices employees will actually use. The restaurant POS hardware matters here: a shared terminal at the host stand may create different login habits from a device used by one server. Ask how staff switch users and how a manager returns the screen to the server without exposing credentials.
A simulation checks the setup without affecting guests. If you later run a live service pilot, train the team first, assign an available approver, and review real exceptions after the shift. Do not turn the practice scenario into a real charge or guest contact.
Review access when roles change or people leave
Permissions need an owner. Choose someone responsible for adding employees, approving role changes, and removing access. Record the person’s role, any exception, who authorized it, and the date it should be revisited. Review the list after promotions and schedule a regular check against the current team roster.
For a departure, remove or disable the individual’s access promptly. Ask whether that action covers every location, device, and connected management area the employee could use. Also ask what happens to active sessions and whether historical transactions remain attributable to the former employee after access is removed.
Ask the vendor to demonstrate the audit history you would use for a review. Can a manager filter by employee, action, and date? Are permission changes recorded as well as transaction changes? Can the history be exported, and how long is it available? Decide who can view it, since the report itself may contain sensitive staff or sales information.
Training should include both the rule and the reason behind the workflow. Show servers how to request help without using someone else’s credentials. Show leads how to reject an incorrect request and what to do if the designated manager is unavailable. A workable policy has a clear path for the exception, not just a blocked button.
Before choosing a system, request a demo of Fleksa and bring your role matrix, the exception scenario, and a list of reports each role needs. Ask the team to show your approval and removal workflows on the devices you expect to use, then compare the results with your written requirements.
Frequently asked questions
Should servers be allowed to issue refunds?
Many restaurants reserve refunds for a manager or an authorized lead. Choose a limit that fits your staffing, then check whether the POS can enforce it and record who approved each refund.
Can employees share a manager login for approvals?
Avoid shared credentials. Individual logins make it easier to connect an approval to a person and remove access when that person changes roles or leaves.
How often should restaurant POS permissions be reviewed?
Review access when someone changes roles or leaves, and check the full roster regularly. Include temporary exceptions and access to connected management tools in that review.
