Food - Tech
A table stops being a list of products and becomes an account with a funding state. Everything downstream changes because of it.
The money is decided before anyone reads a menu. Whether the party can spend past their balance is set once, at the table, in front of them, and it governs the rest of the night.
Limit to credits, yes or no. It decides whether the party can spend past their balance, and it can only be set here. Choosing a service also changes the button, from open table to charge service, because money now moves before anything is ordered.
From here the table carries a balance, and two people watch it for opposite reasons. The guest wants to know how far it goes. The waiter wants to know when to stop suggesting.
Once the table is funded, a bar sits under the menu and above the primary action, counting down live as items go in. Green, amber, red. Nobody has to ask how much is left, and the used total is one tap away without leaving the menu.
The table detail leads with what was ordered and closes with what it means: products, credits available, credits applied, and the one number the waiter will say out loud. Credits are a discount inside the bill, not a separate concept to explain.
When credits cover everything the action is close table. When consumption passes the balance the same screen says charge table, and the difference moves to checkout. No blocking state, no warning: the label carries the state.
Every cash option carries its own change. Exact amount, then the bills a person actually hands over. Change is calculated by the system, not by someone doing mental math with a customer watching. Card brands get the same treatment: one tap, no form.
Card processing takes as long as it takes. Continue in background releases the waiter to the next table instead of holding them hostage to a spinner, and the recap underneath answers the question a guest is most likely to ask while they wait.
A table with unspent credit cannot be closed quietly. The confirmation names the amount and offers to stay on the table. This is the dispute that would otherwise arrive tomorrow. When it does close, the receipt breakdown stays on screen with how it was paid.
The smallest component in the product and the one that carries the most. Visible while ordering without competing with the menu. Readable from a phone held at hip height. Legible to a guest looking over the waiter's shoulder. Colour carries the state, so the number never needs a label.
A funded table has more states than open and closed. Each one changes what the waiter can do next and what they have to say to the person in front of them.
Fully covered by credit
Partial payment pending
Confirming in background
Settled, receipt printed
The bar behaves identically: it counts down live, it changes colour as it depletes, it sits above the primary action. What changes is who is reading it and what they can do about it.
Waiter
Guest
The guest finishes and reads: you have 1,300 in credit left. An invitation to order again. The waiter reaches the same moment and reads: this table still has 1,300 unspent, are you sure you want to close it. One number, one point in the lifecycle, two opposite readings. The system does not have a single voice, it has one per role.
Waiter
Guest
A waiter uses this with the guest sitting right there. That changes what an error is. A failed payment on a personal phone is an inconvenience. The same failure with three people watching is a service problem, and the waiter has to say something out loud while it happens.
That's why confirmation states explain themselves instead of spinning, why the closing guard names the amount instead of asking if you're sure, and why the cash options carry their own change. The waiter should never have to do arithmetic in front of the person paying.
The pattern isn't specific to restaurants. Any venue where guests pay before they consume runs on the same three questions: how much was loaded, how much is left, and what happens to the remainder. Resorts, clubs, event floors. The surfaces change. The account doesn't.
The balance belongs to the table, not to the people at it. When a group splits the bill, there's no record of who consumed what. It works because someone at the table is keeping track, which is a person doing the system's job.
There's no offline behaviour. Background confirmation covers a slow processor, not a dead connection. If the network drops mid-service, the waiter is stuck, and venues with bad wifi are not a rare case.
Scale
Merchants
End users
In production since
Designing operational clarity in high-impact SaaS environments.
Contact me