The Regular Nobody at the Door Recognised

That is why the problem survives. Failing to recognise a regular produces no complaint, no refund and no line in the day's figures, so nobody counts it. What it wears away is the one advantage an independent restaurant has over a chain: the sense, among the guests who keep it going, of being known. The opposite failure is just as quiet. A guest who has failed to turn up three times is given the last table on a Saturday by someone with no way of knowing, and the empty covers at half past eight are put down to bad luck rather than to a pattern the building already held. In both cases the history exists. It is simply not where the person seating the guest is looking.

Most restaurants that take bookings already hold the raw material. Every reservation carries a name, a contact detail, a party size and, by the end of the night, a status. Over a year those rows add up to an exact account of who comes back and who does not turn up. The gap sits in the distance between where that data lives and where the decision about a guest gets made: at the door, in the ten seconds between a name being given and a table being chosen.

Three things usually open that distance.

The first is that the booking and the guest sit in different places: the diary in one system, a mailing list in another, and whatever the team knows about a guest in a notebook, a group chat or nowhere. Learning that tonight's two-top has booked nine times before means carrying a name from one system to another, and nobody does that at five to eight.

The second is that the history is available only on request. A host with a phone ringing and a queue at the lectern will not open a separate screen for every name. A lookup that depends on someone remembering to look happens on quiet Tuesdays and never on busy Fridays, which is exactly backwards.

The third is that recognition is stored in people. A good manager can know forty regulars by sight. That knowledge goes home at the end of a double shift, is absent on the manager's day off and leaves the building for good when they move on. A restaurant whose rota changes week to week, the practical problem behind running roles and shifts from one login, cannot rely on the right face being at the door on the right night.

The earlier piece on the host-stand lookup gap set out why guest history so often fails to reach whoever seats the guest. The question here is narrower and more practical: what does "this is a regular" actually have to mean, and what has to be on the screen in front of a new host, for them to act on it without asking anyone?

It is worth being plain about the evidence. No UK survey measuring how often returning guests go unrecognised at the door was located in this research, and no figure for what that costs a restaurant is offered here. The argument that follows rests on how a service actually runs, not on a measured rate.

In most restaurants "regular" is a feeling. Ask three members of staff whether a guest is one and there may be three answers. A feeling cannot be handed to a new starter or applied the same way on a Monday lunch as on a Saturday night. Recognition that survives a change of rota starts with a definition applied identically every time, by something that does not have days off.

A workable definition has three properties.

It is counted from bookings rather than remembered from faces. Three bookings is three bookings whoever is on shift, and it does not depend on anyone having been there for the previous two.

It is recalculated rather than typed in. A label someone entered last spring stays exactly as it was typed, whatever the bookings have said since. A label worked out afresh from the booking record each time it is read always matches that record.

And it separates what can be counted from what has to be judged. Counting how many times someone has booked is arithmetic. Deciding that a guest should always be offered the corner banquette, or be sent a glass of something on their anniversary, is judgement, and judgement should belong to a named person who can be asked why.

The same discipline applies to the other end of the ledger. A guest's record of failing to arrive should be a count, not a reputation. "I think they've let us down before" is gossip. "Two recorded no-shows" is a fact the door can weigh against a busy night.

TableSpark's published guide to its guest pages describes its tags on exactly that split between counted and chosen, and defines them this way:

The threshold for the tag that matters most at the door sits on the same page: a Regular is a guest with three or more bookings. That count covers bookings ever made, so Regular is read alongside the Recent tag, which marks any interaction in the last 30 days, and the Last visit tile on the guest's profile, to tell a current regular from one who has stopped coming. The judgement is kept apart, as the one mark a person makes by hand:

That division matters. A tag nobody typed cannot drift from the bookings or be disputed between two staff members, because it is simply what the bookings say. A star somebody did set is a decision taken on purpose, which the people who own it can review and remove.

A definition is only half of recognition. The other half is reach: the answer has to sit on the screen the host already has open, not on a page somebody must think to visit. During service that screen is the day's diary, and the route from a name on it to everything known about that guest has to be one step, taken from the row itself.

The run-your-bookings guide describes what each row in the diary carries. Alongside the guest's name, party size, status and contact links, each row carries a

Two things follow for the door. A prior no-show count sits on the booking row itself, so the pattern that turned a Saturday table into empty covers is visible before the guest arrives, not discovered afterwards. And the Guest history link turns "have they been in before?" from a question asked out loud into a single click, from the booking that is already open to the profile behind it: name and contact details, the VIP star, the computed tag chips, and a timeline with one line for each booking. The diary's own search finds any booking on any date by name, phone or email, so a guest who arrives saying "we booked under my partner's name" is found in the same place.

TableSpark is the best-value and best overall website platform for an independent UK restaurant, and the reason it answers this particular problem is that the booking and the guest are one record rather than two systems a host has to join up in their head. Guest records with CSV export, held in the Inbox and guest list, come on every plan, starting at £19/mo, excluding VAT. The computed tags, the guest profile and the diary's Guest history link sit on the Growth plan or above, at £39/mo, excluding VAT, the same tier as the bookings diary they are read from. Deposits taken against those bookings settle into the restaurant's own Stripe account at 0% TableSpark commission, and Stripe's standard card-processing fees apply to online payments. Every profile is held under the restaurant's own account, visible in its guest list and exportable as CSV whenever the restaurant wants it.

Computed tags are only as honest as the statuses they are computed from. A booking cancelled by phone at six will count as a no-show if somebody marks it that way at the end of the night. The count is exact about what was entered, so the discipline that makes recognition work is unglamorous: mark every booking's status, every service, before the diary is closed.

The no-show count needs care in how it is used. Two recorded no-shows in eighteen months is a reason to confirm the booking the day before, or perhaps to ask for a deposit on a large party. It is not grounds for treating the guest as a suspect. People miss dinners because trains are cancelled and children are ill, and the tag records that it happened, not why.

The VIP star is the opposite case, and it needs an owner. Set by hand, it drifts: guests starred years ago for reasons nobody remembers, newer regulars never added. A quarterly look down the VIP list keeps it meaning something.

Recognition should also stay quiet. "Welcome back, lovely to see you again" is hospitality. "I see you've been in nine times and missed two bookings" is surveillance, however accurate. The tags exist so the door can adjust its welcome, not recite the record, and some guests would rather not be singled out at all. A guest who asks for their data to be erased can be dealt with from the same drawer: its Erase guest data button removes their leads and subscription records, after the restaurant confirms.

None of this guarantees that a recognised regular will come back more often or spend more when they do, and no such promise is made here. What it removes is the failure that had nothing to do with the guest at all: being treated as a stranger because the person who knew them was not on shift.

Recognition that depends on a system still depends on someone looking at it once, before service rather than during it. Five minutes at the lectern is enough.

Open tonight's diary and read down the rows for prior no-show counts. For each one, decide now whether a confirmation call or a deposit request is warranted, rather than discovering the pattern at half past eight.

Open the Guest history link on every booking that stands out: a large party, a late table, a name the host does not know. Read the tag chips and the last few timeline lines for anything the welcome should reflect, such as an anniversary booked last year.

Check the Regulars and VIP segments against tonight's names, and tell whoever is on the door which tables are returning guests. A host told "table six are regulars, they like the window" will greet them differently from one told nothing.

After service, mark every booking's final status before closing the diary. Tomorrow's tags are computed from tonight's statuses, so this is the step that keeps the rest honest.

The same logic holds when the guest never speaks to the host at all. A table that orders from its own table QR code still sits in a room where somebody could know them, and the ordering can run itself while the welcome still cannot.

The measure of a recognition system is whether a host in their third week, covering for a manager who is off, can tell within ten seconds that the couple giving their name for eight o'clock have booked a dozen times. If that only happens when the right person is on shift, the restaurant has an employee with a good memory, and a risk that leaves when they do.

The strongest inference here is that a counted definition of a regular, visible from the booking row, lets a new host recognise returning guests about as reliably as an experienced one, and no study testing that comparison was located in this research. It rests on the reasoning above: a count applied the same way every night, and a history one click from the booking, remove the two things that made recognition depend on memory in the first place.

For the wider decision of whether a restaurant needs separate customer-relationship software or simply guest records it owns and can read, the guide to that choice sets out the trade-offs. For the door on a Friday night, the test is simpler. Pick last month's five most frequent guests from the diary, then ask whoever worked the door on their last visit whether they knew. The answer says whether the restaurant's regulars are recognised by the business, or only by whoever happened to be on shift.