When The Card Machine Is The Queue

The night went well. Then eleven tables all want to pay within the same twenty minutes.

The last thing a guest experiences is waiting, and it colours everything before it.

Why it concentrates

Not bad luck. Structural, and therefore predictable.

Closing time is shared. Everyone leaves near the same moment because you told them when the moment is.

Splitting takes disproportionate time. A group of six paying separately is six transactions, six confirmations, and usually one card that fails.

The bill gets assembled at the point of asking. ⚠️ If the total is calculated when it is requested rather than maintained during the night, every request starts from zero.

Staff are simultaneously closing. The people who process payment are the same people clearing, cashing up, and getting others out.

The four bottlenecks

One terminal. ⚠️ The most common and the most fixable. A second device costs little against twenty minutes of queue every night.

Assembling the bill. Anything from thirty seconds to several minutes if items are on paper or in someone's memory. This is usually the largest single component and is rarely measured.

Splitting. Slow by nature, and much slower if the split has to be worked out at the table.

Disputes. One query stops a queue entirely, because the person resolving it is the person processing everyone else.

What actually shortens it

A running total, maintained during the night. ⚠️ This is the one that matters most. If the bill exists continuously, presenting it is instant and the twenty-minute crush becomes a sequence of short interactions.

A second terminal. Trivially cheap against the cost of the queue.

Ask groups earlier how they intend to split. Once, mid-evening, not at the end. The arithmetic then happens when there is time for it.

One person who handles queries only. ⚠️ Not the person taking payments. A single dispute otherwise blocks everyone behind it, which is how a five-minute queue becomes fifteen.

The thing nobody counts

How long the last guest waited.

Venues measure covers, spend, and sometimes service times — almost none records the gap between asking to pay and leaving. ⚠️ It is the final impression of the entire night and it is the least observed number in the building.

Two weeks of rough timing is enough to know whether you have a problem.

The version that is worse than a queue

Getting it wrong under time pressure.

A rushed split that shorts someone, a total that includes another table's round. ⚠️ A guest who waited ten minutes is mildly annoyed. A guest who was overcharged tells people — and the correction costs more staff time than the queue ever did.

Speed that produces errors is not speed. It moves the cost somewhere less visible and more expensive.

Three to hold

Time from bill requested to guest departed. The number that is not being kept.

Transactions in the final thirty minutes. ⚠️ Shows the size of the concentration and whether it is worsening.

Payment corrections per week. The cost of hurrying, which otherwise appears nowhere.

Where the record has to sit

A running total requires orders to be entered as they happen rather than reconstructed at the end. Venues that write on a pad and total it at close cannot present a bill quickly no matter how many terminals they buy, because the bottleneck is the assembly and not the payment.

tasteck keeps orders against the table as they are placed, so the total is current at any moment rather than calculated on request.

The queue is not at the card machine. It is at the point where somebody works out what the table owes.