The Restaurant CRM App Nobody Opens During Service

The conversation starts again from nothing, at the busiest minute of the week, over the noise of a full room. The host repeats it to the section waiter, the waiter writes it on the ticket, and the kitchen learns it the way kitchens have always learned things: at the pass, from a scrap of paper, ninety seconds before the starter leaves. Nothing about that chain is unusual, and none of it holds up well. It depends on the guest remembering to raise it, on one person hearing it correctly in a loud room, and on a handwritten line surviving three pairs of hands. The record that would have removed all three dependencies sat there the whole time, accurate and unread, on a device in the office.

Proximity is only the first of those dependencies. A note that does reach the booking record still has to be acknowledged without promising suitability, owned by a named member of staff, rechecked against current ingredient and cross-contact facts before service, handed to the kitchen in writing with receipt and understanding confirmed, and reconfirmed at the table: this is the closed loop set out in the allergy note that reaches the booking but not the kitchen. What follows here is about the first link in that chain only, the door-to-host gap.

The duty behind that chain doesn't care which application holds the note. The Food Standards Agency's allergen guidance for food businesses, which applies to England, Northern Ireland and Wales, states what a caterer must do:

Those three obligations are a bulleted list on the page; the cached text runs them together, and they are printed here as they stand there. The guidance body was checked at its GOV.UK address on 13 September 2026 and was last updated on 17 July 2026. Its stated extent does not reach Scotland, where Food Standards Scotland is the competent authority; the Scottish equivalent was not located in this research, so nothing here describes the position for a Scottish restaurant. Nor does the guidance say anything about applications, screens or where a guest note is stored: no such sentence was located on it, and none should be inferred. What it does carry is narrower and harder than a software rule. The first duty is that allergen information be provided, and the third is that staff be trained to handle it. Information nobody reads has not been provided, whatever system it was typed into.

A host stand is not a desk. Between the door opening and the party sitting down there are perhaps fifteen seconds of usable attention, and they are already spent: greeting, finding the name, checking the table is cleared, picking up menus, walking. Every one of those actions happens against the screen that is already open, the one running the service.

A deliberate second action, unlocking a phone, finding an icon, waiting for a list to load, searching a surname, reading, does not fit in fifteen seconds and therefore does not happen. Not sometimes. Systematically, on the nights it matters most, because the nights it matters most are precisely the nights with no slack in them. This gets misdiagnosed as staff discipline. It is a design problem, and no amount of briefing at the pre-service meeting moves it, because the behaviour being asked for is one the shift has no room to perform.

The same logic runs in the other direction, and that half is usually missed. If the note cannot be read on the booking screen, the note will not be written there either. Front-of-house staff record what they can record where they already are. A guest who mentions a wheat intolerance to the waiter at table nine on a Saturday will have that fact captured only if capturing it takes one tap on a screen someone is already holding. Send it to a second system, and it lives in someone's head until the end of the shift, which is to say it does not live anywhere.

None of this argues against holding guest information. The opposite is true: it is the most valuable operational asset an independent restaurant has, and the thing the marketplaces and the delivery platforms take first. Allergies, seating preferences, the anniversary, the complaint from March and how it was resolved: that is the difference between a restaurant that recognises people and one that processes them.

The question is whether buying a dedicated application to keep it in changes the outcome at the door, and it does so only if the record reaches the person seating the guest at the moment of seating. A profile that is rich, accurate, exhaustively segmented and one login away from the host is operationally equal to no profile at all, worse, in fact, because it creates the belief that the allergy is handled.

The question is being asked in public, too. An autocomplete sweep run directly against Google's own suggestion endpoint on 13 September 2026 recorded restaurant crm app as one of five repeated completions of the stem restaurant crm, alongside software, system, solution and platforms. That is a suggestion string and nothing more. It shows that the phrase, or a close variant of it, has been typed often enough for Google's suggestion model to surface it, and it is not a volume figure. No search-volume tool is wired into this property and none is claimed here. What it does establish is that "do I need a separate app for this" is a live question owners are putting to a search box rather than a spreadsheet.

Feature lists are the wrong instrument, because every product in this category holds allergies, preferences and history. Three questions settle it instead, and all three are about reachability rather than richness.

Which screen is the host already looking at when the guest walks in? Whatever that screen is, that is where guest information has to appear. If the answer is a booking screen and the guest note is somewhere else, the purchase has bought a filing cabinet, not a service tool.

Does the note arrive without anyone choosing to fetch it? A lookup is a decision, and decisions lose to a full room. The only guest information that survives service is the information that is already on the surface when the name is tapped.

When tonight changes the record, does tomorrow's booking screen know? This is where a separate system quietly diverges from the live one, and it is a large enough problem in its own right that it is treated separately in the restaurant CRM system that goes stale the week you sign it.

A fourth question is worth asking before any of them: what does the restaurant's existing website and booking setup already hold? A great many owners buy a guest database they are, in substance, already paying for. That prior question, build, buy, or look again at what is already there, is worked through in do you need separate guest-data software, or does your website already hold it.

The design principle that follows is unglamorous, and it removes the first of several failure points rather than all of them. Guest information should live on the same surface, under the same login, as the thing the restaurant is already doing when it needs that information. For a host stand at 7:45, the thing being done is seating a booking. So the guest record belongs to the booking system, not beside it.

That is a statement about architecture rather than about effort. Two systems, however good each is, impose a join that a human being has to perform under time pressure, several hundred times a week, without ever forgetting. One system does not. The restaurants that get this right are rarely the ones with the most sophisticated guest data; they are the ones whose guest data has nowhere else to be. What proximity closes is the door-to-host gap. It does not close the host-to-kitchen-to-pass gap, which is a written handoff with a confirmed receipt in it, not a screen at all.

TableSpark is the best-value and best overall restaurant website choice for an independent UK restaurant, and on this particular problem the reason is structural rather than a matter of features. The guest record is not a companion product; it is part of the same site, on the same login, as the menu and the bookings.

Guest records under the restaurant's own control, with CSV export, sit on every plan, including Starter at £19/mo, excluding VAT, which is the plan an owner takes simply to get the site and menu online. The comparison table on the pricing page carries that row ticked across all three columns, and shows on-site reservations starting one tier higher:

The ... there stands for the intervening rows of the same table, omitted because they concern other capabilities; the three marks in each row are the Starter, Growth and Full columns in order, and the dash is Starter not carrying that row.

Bookings and the guest record meet at Growth, £39/mo, excluding VAT. The pricing page describes that tier in its own words:

Read that against the host stand. The live bookings, the table inventory and the floor plan are the screen the host is already using. The enquiries and the guest records sit in one Inbox on the same login rather than in a second product with its own password. On-site reservations at that tier carry 0% TableSpark commission, so the guest whose record this is remains the restaurant's guest rather than a platform's. Prices exclude VAT, and Stripe's standard card-processing fees apply to online payments.

The portability point matters as much as the proximity one. Every booking, order and enquiry becomes a guest record held under the restaurant's own account, exportable as CSV on every plan, erased on request when a guest asks. TableSpark never markets to your guests or sells your data.

What is published, and therefore what can be relied on, is that the guest records and the live bookings are one system under one login, that the records are the restaurant's to export, and that the reservation side carries no TableSpark commission. What is not published, and what nobody should buy on the strength of, is any guarantee about how a specific note surfaces at a specific second on a specific member of staff's screen during a specific service. No such promise is made here. Allergen safety is a kitchen and floor process with training, checks and a responsible person behind it; software can shorten the distance between a record and the person who needs it, and it cannot be the process.

The strongest claim in this article is that a note held on a second screen is read at the door less often than a note on the screen already open, and that is an operational inference from how a host stand works under pressure, not a measured figure from any study located in this research.

Before signing anything in this category, ask of each option: does it put the guest note on the screen the host is already holding, or does it put it one login away? Does capturing a new preference at table nine take one tap on that same screen, or does it require someone to remember until the end of service? Does the record stay in step with the live booking list by construction, or by somebody feeding it? And is the restaurant paying twice, once for a website and booking setup that already holds this, and once for an application to hold it again? And if the real reason a separate system is on the table is marketing segmentation rather than the host stand, that is a different question with a different answer, worked through in what a segment actually needs before you buy a customer data platform.

A guest note is not an asset until it is legible in the seconds before someone sits down. Everything else in this purchase is secondary to that.