The guest
On their own phone.
Sits down, scans the code the waiter shows them, and taps Call when they want something. There is no app to download, no account to make, and no need to catch anyone’s eye.
Setting up takes one sitting. After that the same four steps repeat every service, and none of them need an app, an account or anything screwed to a table.
Every call crosses three screens. Each person only ever sees the part of it they need.
On their own phone.
Sits down, scans the code the waiter shows them, and taps Call when they want something. There is no app to download, no account to make, and no need to catch anyone’s eye.
On their own phone, and on the shared screen if there is one.
Opens a table at the start of service and answers calls during it. Opening happens on the phone in their hand, because that is what carries the code to the table. They see the tables they are assigned to and nothing else, so a call is never somebody else’s problem.
On a laptop off the floor — and on the shared screen, if the venue runs one.
Adds the venue, the tables and the staff, then assigns who covers what. Their call view is the one that shows every table at once, which is why the shared screen on the floor is signed in as the manager. Later they can read back how often each table called and how quickly it was reached.
These are the same four steps summarised on the home page, with what each side actually sees.
The manager adds the venue, adds each table, and invites the waiters by email. Then they assign tables to the people who cover them. This is the only part that is not a single tap, and it happens once.
At the start of service the waiter opens a table on their own phone, and that table’s code appears there for the guest to scan — the phone goes to the table, so nobody has to walk to a screen. The session it opens has a time limit, so yesterday’s code cannot raise a call today.
The guest scans, and one Call button opens in the browser they already have. Nothing else is on the screen: no menu, no sign-up, no order to build. They tap once, and the button reads Calling… back to them so they know it went.
The table turns Calling… on the assigned waiter’s list, carrying a colour, an icon, a word and a sound, so it reads across a dim room without anyone stopping to look twice. It stays that way until a waiter acknowledges it or the guest cancels.
Every call and every change of state is written down as it happens. That record is what the manager’s reports read back later: calls by day and by hour, the tables that ask most often, and how long each one waited.
A call only helps if somebody sees it, and a code only helps if it reaches the table. Those are two different jobs, and the two screens below are not alternatives. Sign in on both.
A tablet at the pass, or any spare screen mounted where staff walk past it, is the surest way to guarantee a call is seen: it is always on, always charged, and nobody has to have their phone in their hand. It is signed in as the manager, so it shows every table rather than one waiter’s — and each action taken on it, from opening a table to acknowledging a call, asks for that waiter’s own PIN, so it is still recorded against the person who did it.
Waiters are signed in on their own phones at the same time, and see the tables they cover. A call raised at table 12 shows on every screen that covers table 12. This is not a fallback mode: it is the only screen that can be held out to a seated guest, so it is where a table gets opened and where the guest scans the code.
Neither screen is complete on its own. A screen mounted at the pass cannot be carried to table 12, so it cannot hand anyone a code; a phone in a pocket cannot be relied on to be looked at. Run both and each covers the other — they act on the same live session, so a code opened on one can be re-shown on the other, and it never matters which screen started it.
Create an account, add one table, open it, and scan the code with a second phone. That is the whole loop.