Give waiters, kitchen and cashiers a focused workspace
A waiter should not search through accounting to take an order, and a cashier should not receive payroll access merely to find checkout. Separate accounts and focused tools reduce distraction while preserving the permissions that actually protect data. Start by describing duties, then test each account against those duties.
Before using this with live customers
Start in a fictional training workspace with a small catalogue, named staff and known opening quantities. Decide what the operator should be able to do, which branch owns the work and which evidence will show that it succeeded. Check the installed edition and build before following a new control. A plan entitlement, a workspace switch and a staff permission are separate checks. Hiding a menu simplifies the view; it never grants permission to the underlying operation. Keep administrator credentials private and give each employee an account that matches their responsibilities.
A short, repeatable acceptance exercise
Write down the starting record and the expected result before making the change. Use one ordinary item and one edge case: a decimal quantity, a modifier, a discount, a missing cost or a long Arabic product name, depending on the task. Perform the action once, inspect its saved record, then reopen the screen in a separate session. Verify that the original identity and totals survived. If a button disappears, examine role, feature switches and branch scope before assuming that data has been lost. A fictional demonstration is evidence of that tested workflow, not of every possible customer configuration.
Online / SaaS
Roles, duties and branch access
- Open Team as owner. Create a separate account for each employee; do not share the manager password.
- Assign actual rights and permitted branches. Give waiters table/service tools, chefs kitchen tools and cashiers checkout tools; an employee with several authorized roles can switch workspaces.
- Test the account in a separate session. The role landing page, menus and finder should show only authorized tools. A hidden link never grants or removes server permissions.
- Use the read-only accountant preset for inspection and exports. Test a write refusal before handing over the account. Revisit rights when duties change.
Choose a focused business workspace
- Sign in as owner or manager and open Settings → Business type & features. Choose the branch first; a branch can inherit the shop default or keep its own choice.
- Select retail, restaurant/cafe, grocery, butcher, bakery/production, wholesale, services or mixed business. Select the appropriate subtype. Choosing a type does not save it.
- Review the enabled, hidden and unavailable tools. A hidden tool is a presentation choice; an unavailable tool needs the relevant entitlement. Inspect the reason next to each default.
- Choose whether to keep custom choices or apply suggested defaults. Save the reviewed workspace. Return here to change individual switches; finish open table bills and kitchen work before hiding their tools.
Classic Desktop / Windows
Roles, duties and branch access
- Open staff management as the local administrator. Create a separate local account for each operator.
- Set cashier rights for the work that person performs. Do not share the administrator password to bypass an absent control.
- Sign out and test the account, including refusal of an unauthorized refund or settings change.
- Local accounts and cloud Team accounts are separate. Pair the cloud till and use cloud credentials when working against the online shop.
On classic Desktop, manage local staff and cashier rights in the program. Local staff records are distinct from online team accounts. Pair and sign into a cloud till to use cloud accounts; do not assume local users automatically become cloud employees.
Choose a focused business workspace
- Open the Windows program and choose the shop type and optional features in Settings. Keep the shop currency and tax settings consistent with the receipts you issue.
- Review the enabled native tools with the operator before starting. Browser branch-inheritance and workspace review screens belong to SaaS and are not native screens.
- Create local staff accounts and test a cashier session. A cloud-connected till instead signs into its online shop and follows its authorized cloud settings.
- Back up the local data before changing a working installation. Finish open table orders before changing their feature settings.
The classic Windows program uses its own shop-type and optional-feature settings. It does not contain the browser’s branch-inheritance review screen. A cloud-connected till follows the online shop’s authorized feature settings.
Review the evidence rather than the animation
A preview is not a posted movement, an accepted request is not provider settlement, and a queued message is not verified delivery. After a financial or inventory action, inspect the original receipt or movement before retrying. Keep the original request identity for an uncertain replay. Do not create a new sale merely because the first response was slow. For exports, compare the selected range and totals with the source report. For staff reports, distinguish an actual event from a missing timestamp. Do not turn missing data into zero seconds or a claim that an employee did no work.
Keep edition and external-service limits explicit
Classic Desktop, a cloud-connected till and the SaaS browser share concepts but do not expose every control in the same place. The sections below give separate procedures and explain real alternatives. Follow the manual for the edition you are actually using. Device compatibility still requires the exact model and protocol to be tested. External payment, accounting and dashboard services require their own account, authorization and configuration. This article does not promise a live delivery-platform integration, a new paid-plan inclusion, a hardware supply service or an approved wallet pass. Confirm those conditions separately before a customer commitment.
Actual interface reference images
