Peak hour: where the seconds go, and how to get them back

In most Saudi restaurants, the two hours around Maghrib and Isha produce a large share of the day's revenue. A counter that is thirty seconds slower per transaction during those hours serves meaningfully fewer customers, and the customers it loses are the ones who looked at the queue and left.

Here is where the seconds actually go.

Count the taps

Take your five most common orders and count the screen taps from start to payment. Do it yourself, on your own system.

A well-configured system should handle a common order in 4–6 taps. If yours takes 12, the problem is almost always configuration rather than software.

Where the extra taps hide:

• Items buried in sub-categories instead of on the first screen
• Modifiers that require a confirmation tap nobody needs
• A payment flow asking for a customer, an email, and a tip when none apply
• A "are you sure?" dialogue on an action that happens forty times an hour

Fix the button layout

Put your top 20 items on the first screen. Look at last month's sales and lay out the screen from the data, not from the menu's structure. The menu is organised for customers; the till screen should be organised for cashiers.

Group by how people order, not by how the menu prints. If "karak and a croissant" is a frequent pair, they should be adjacent.

Colour-code by category. Staff navigate by colour faster than by reading, particularly under pressure.

Review it monthly. Sales mix drifts, and a layout laid out at opening is wrong within a season.

Fix the modifiers

Modifiers are where the taps multiply.

• Defaults should be the common case. If 80% of the coffees are medium, medium should be pre-selected.
• Only ask what varies. A modifier that is always the same is not a modifier; it is part of the item.
• Combos should be one button. If a meal is ordered as a set, it should be a set button, not four items.
• Limit the depth. Two levels maximum. Three levels of nested modifiers is where staff start guessing.

Fix the payment flow

• One tap for the common payment method. If most people pay by card, "card" should be one tap from the total.
• Exact-cash buttons. SAR 50, SAR 100, SAR 200 as single taps.
• Do not ask for a phone number on every sale. Make it optional and quick, or offer it only when the customer asks for a digital receipt.
• Print should not block the next sale. The cashier should be able to start the next order while the receipt prints.

Remove the manager bottleneck

Watch a peak hour and count how often a cashier stops and looks for a manager. Every one of those is 30–90 seconds.

Usually it is one of: a discount, a void, a price override, a refund.

Fix it by delegatingwith limits rather than delegating fully: let a cashier discount up to 10%, or void within two minutes of ringing. Above that, a manager approves — ideally from their own device rather than by walking over and typing a password in front of everyone.

Printers and network

Two boring things that cost more peak-hour time than any software feature:

Printers should be wired. A wifi printer that drops mid-service costs minutes, not seconds.

The network should be sized for the room. A consumer router serving twelve devices in a busy restaurant is a false economy. Wired runs to the printers and a proper access point cost less than one bad evening.

Measure it properly

Your POS should be able to tell you:

• Transactions per hour by terminal
• Average transaction time
• Time between order and payment
• Which items appear in the slowest transactions

Look at these for your peak hour specifically, not for the day. The daily average hides exactly the period you care about.

The one change that usually helps most

A second till for the peak two hours only. A browser cashier on a laptop, opened at 18:00 and closed at 21:00. No extra hardware purchase, no extra subscription at most tiers, and it halves the queue during the hours that matter.

Wameed's browser cashier works on any machine and also works offline; see thefeatures page.