Know where preparation and service time goes

Elapsed time since an order began cannot explain which stage took too long. Preparation, readiness, service and payment are different events. Treat missing timestamps as missing evidence, and compare similar work over the same period before deciding that one employee is faster than another.

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

Kitchen progress, service timing and cleaning

1. A chef opens their kitchen workspace and claims work for the appropriate station. Record Start, pause/resume with a reason, Ready and any rework or waste accurately.
2. A ready kitchen item alerts the assigned waiter. The waiter claims ready service and marks Served only after handing it to diners; Ready and Served are different events.
3. Review the order/visit timeline for immutable timestamps, actors and reasons. Compare similar stations and preparation types rather than ranking staff on incomparable work.
4. After final settlement and checkout, the table requires cleaning. Claim cleaning and mark it complete before the next visit. Settling one guest share does not close the visit for the remaining diners.

Open the edition manual

Employee sign-in and HR workspace

1. Create the employee and permitted duties as owner/HR administrator. Separate attendance rights from selling, payroll approval and staff-performance access.
2. When attendance sign-in is enabled, use the employee’s own session to clock in. Confirm the current shift/attendance state; a shared login cannot establish a reliable individual attendance history.
3. Open the authorized HR workspace for attendance, schedules or employee self-service. Employee pay and private staff information stay behind their existing rights and branch scopes.
4. Inspect missing punches, exceptions and approved corrections before payroll/reporting. A separate HR hostname needs actual DNS/TLS and deployment; the same credentials do not prove an unconfigured subdomain exists.

Open the edition manual

Classic Desktop / Windows

Kitchen progress, service timing and cleaning

1. Open Tables and inspect the held order for the selected table.
2. Review the ordered items before completing payment. Do not recreate a held order after an uncertain save.
3. Complete the native receipt and verify the table/order state.
4. SaaS kitchen action timing, waiter notifications and the cleaning lifecycle are not classic Windows controls. Use the Online workflow for those operations.

Open the edition manual

Classic Desktop kitchen tickets and held orders are separate from online immutable visit/service events. Do not claim the browser cleaning roster or staff performance dashboard exists in the native program. A cloud-connected restaurant may use the online kitchen and waiter workspaces alongside its till.

Employee sign-in and HR workspace

1. Open local staff management for operator identity and available local attendance features.
2. Keep a unique account for each employee and verify which rights that account has.
3. Use the Online HR guide for cloud attendance, shifts, role-focused workspaces and cloud HR reports.
4. Local staff records do not automatically become cloud employees, and a receipt cashier name is not a full HR attendance record.

Open the edition manual

Classic Desktop keeps its native staff, attendance and staff-ledger files. The online HR suite’s scheduling/payroll/employee pages are separate. Do not describe every online HR module as installed in standalone Desktop.

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