Software demos usually show a guest tapping a dish and a green confirmation arriving on cue. A busy shift rarely behaves that politely. Before giving a tablet to the counter team, train around what happens when something is missing, the wrong person taps, or a waiter swaps sections. Here is a short drill you can run with demo data and a whiteboard.
Minutes 0–5: define the states in plain language
Ask the group what 'request received', 'accepted', 'assigned', 'served' and 'visit closed' mean. If two people give different answers, align the language before testing a screen. In particular, receiving a guest request is not the same as accepting it, and accepting is not a guarantee that preparation has begun. The status message seen by guests should agree with the operation staff actually performed. Write one sentence per state where the whole team can see it.
Minutes 5–12: practice one ordinary table
Give a guest test phone to one colleague and a counter test screen to another. Have them browse a menu, submit a harmless sample request, accept it and assign a waiter. The waiter should find the table and repeat the request back. This is a rehearsal—not a real order. Check whether a person who didn't configure the system can tell what needs their attention. If they need the developer standing behind them, the workflow isn't ready for the floor.
Minutes 12–20: deliberately make three mistakes
First, submit a sold-out dish and have the counter reject or correct it without falsely telling the guest it is being prepared. Next, open the same table on a second phone and check that the staff understand the requests belong to one visit. Finally, assign the wrong waiter and practice transferring the job. Record where someone hesitates. Do not 'fix' the test by pretending the problem wouldn't happen on a busy Saturday; mistakes are the most useful part of the drill.
Minutes 20–26: close the visit once
Have a colleague add a late request, then ask the counter what should happen before closing the table. A restaurant-controlled final statement should represent the entire visit, not one phone or one intermediate order. Confirm that payment remains with the restaurant's ordinary cash, UPI, card or POS process. KyaLoge does not process a guest's meal payment. No official bill or real email should be sent during this rehearsal unless an approved pilot explicitly authorises it.
Minutes 26–30: decide who owns the next shift
Pick a shift champion who can answer basic questions and escalate a problem. Keep a one-page reference with the five states, two emergency contacts and a paper fallback. End by asking the newest team member—not the manager—to explain what happens after a QR scan. Their answer is a better readiness signal than a beautiful animation. If the answer is unclear, repeat the drill before opening the pilot to more tables.
An exercise you can run before the weekend rush.
Put a guest phone, a counter screen and a waiter in one room. The test is not whether everyone remembers the login. It's whether they can recover from a sold-out item and an incorrect table without a manager explaining each tap.
Who should be allowed to say an order is accepted?
The designated counter or authorised restaurant role—not the guest device simply because a button was pressed. Communicate the distinction clearly on every screen.
What if a staff member leaves while an order is open?
Have a named shift owner and a documented reassignment route. Try the transfer in the training exercise. If the new waiter cannot discover the task, the handoff needs redesign.
Ask the newest waiter to explain the flow in their own words. That's a better training result than a colourful dashboard.
What to check before making a decision
- 01Define request/acceptance/assignment/serving/closure in ordinary language.
- 02Rehearse with sample data and no actual guest messages.
- 03Test a sold-out dish, a second device and a wrong waiter.
- 04Confirm only authorised counter staff can close a visit.
- 05Keep an escalation owner and paper/human fallback.
Keep the useful part.
A useful onboarding session makes a team calmer under pressure. It should leave staff knowing how to recover when the usual flow doesn't work—not merely which green button to press.
Editorial note. This guide was prepared for restaurant operators using illustrative examples, not customer research or independent professional advice. Verify any legal, tax, dietary or platform-specific requirement with the relevant authority.