Guides

Peak continuity: which steps to test when busy

Open-table, edits, kitchen send, pay, split and void must be run by on-shift staff when busy; verbal promises do not count as verified.

Saturday 12:40. Queue at the door, hot pass chasing tickets. Cashier must change a soup, merge two tables, split one check, send to kitchen, then take payment. One step sticks — everything behind it stops. Peak continuity is not the sentence “the system is stable.” It is whether these steps can still be finished by the person on shift, alone, when it is busy.

Test with this shop’s menu, prices and equipment. Ordinary shift staff. No coaching on site. Each step gets only three results: pass, fail, still unknown.

The steps that must still work when it is busy

Cover at least what this shop uses: open a table or ticket; change (qty, modifiers, notes); send to kitchen or pass; payment (cash, card, and the mixes you actually use); split or partial pay; void (before and after fire, separately, if you do both). If you also transfer, merge or takeaway, put them on the list. Do not replace them with the showroom coffee.

Scene: merge tables works in an empty room. At lunch two tables merge, one already fired; after the merge the kitchen paper reprints. Guests are still waiting for the second course. Mark fail. Do not flip it to pass because “it worked when empty.”

If this shop never does a step, strike it and note why — do not pretend you tested it. If you do it but cannot test it, mark still unknown and write what is missing (which device, which shift, whose authorisation).

Who tests, and under what load

Name the person who worked last Friday or Saturday peak. The manager may watch. They may not click or prompt. Pressure must be real: several people at once, chased tickets, rushed changes — still combinations this shop actually hits. Do not invent a “limit test” flow this shop has never run.

Scene: sales stands at the shoulder and says “click here.” Cashier follows; the step passes. After sales leaves, the same person alone sticks on send-to-kitchen. Scrap the coached result; put the cell back to still unknown until it passes alone.

Note delays, vague prompts, extra hand steps. Anything added while guests wait goes on the sheet. Do not only write “it got done in the end.”

Pass, fail, still unknown: leave blanks blank

A verbal “fine at peak” is not a pass. Done only in a showroom or off this shop’s network is not a pass. Device not on site that day, permission missing that day — still unknown, and write when you will retest.

Scene: the card path row is empty, and someone is already talking cutover date. An empty row is not small. If peak payment cannot run, open / change / send were wasted. While unknown cells remain, peak continuity is not done.

Until these busy steps pass alone, do not write “service continuity” into the comparison conclusion.

Back to Stay or switch? Restaurant POS Hungary checklist.