Most independent restaurants that take allergen management seriously have some version of the same system. A spreadsheet (sometimes printed, sometimes digital, sometimes both) listing the dishes on the menu and which allergens they contain. This is usually kept somewhere on premises: behind the bar, in the kitchen, in a folder the manager knows about.

It's a reasonable response to a real need. It's also, broadly, what the industry has standardised around: the FSA in the UK provides allergen matrix templates for exactly this purpose, and the spreadsheet approach is what most food safety guidance points businesses towards. But it has limitations that only show up under pressure.

What the spreadsheet is built to do

The allergen spreadsheet is a reference document. A staff member consults it or provides it to the customer when they ask. It shows the 14 major allergens and which dishes contain them.

The design is sound. The practical reality is where things come apart.

The update problem

Menus change. Specials rotate. Suppliers change ingredients. A sauce that was nut-free yesterday might not be today because the supplier reformulated it. A new dish gets added. An existing dish gets an ingredient swap.

Every time any of these changes happen, the spreadsheet needs updating. In a restaurant where the owner or manager is running service, managing staff, handling bookings, and doing a dozen other things simultaneously, updating the allergen spreadsheet is exactly the kind of task that gets deferred to tomorrow, then next week, especially when its a separate document from the main menu. This is just the practical reality of running a busy restaurant with a small team.

There's another problem that comes with this. Updating a physical spreadsheet properly means redoing it; adding a column, adjusting a row, reformatting to account for a new dish or a changed ingredient. In practice, changes get added in whatever space is available: a note in the margin, an extra row that doesn't quite fit the structure. Over time, the document becomes harder to read, harder to trust, and harder to hand to a customer.

That last point matters because I've repeatedly been in this situation. Sometimes I'm told the spreadsheet is too hard to follow and I'm left relying on the server to interpret it for me. Other times I'm handed it directly and it's so patched together, so covered in amendments and margin notes, that it's effectively unreadable.

Two different outcomes, same root problem: the restaurant had the information. They just couldn't share it in a form that was usable.

The access problem

Where is the spreadsheet? This sounds like a simple question. Ask three members of your front-of-house team right now and see if they all give the same answer.

In a busy service, when a customer asks a question, the staff member needs to find the document quickly, locate the right dish, interpret the information, and communicate it clearly – all while tables are waiting and the kitchen needs plates to walk. Making a staff member the only route to that information is where things start to go wrong.

There's a customer side to this too. The spreadsheet behind the bar is invisible to anyone who hasn't walked through the door yet. A customer researching restaurants at home, trying to work out whether they can eat safely before they book, has no way to access it. If the information isn't available online, the restaurant isn't being considerated at all.

The information relay problem

Whether the customer gets to see the spreadsheet or not, there are challenges either way.

If the spreadsheet given to the customer, the format rarely provides all of the information. A grid of ticks tells you whether an allergen is present or not, but it doesn't tell you what component of the dish it’s in, how it’s prepared, whether there's a cross-contamination risk, or whether a modification is possible. The document answers a narrow question and leaves most of the real ones open. That means back-and-forth between the customer and staff is still necessary; the customer seeking clarity on what the document couldn't provide, and the staff trying to fill in the gaps from memory or by going back and forth to the kitchen.

If the spreadsheet stays behind the bar and acts as an internal reference only, the information is completely reliant on verbal delivery. That relay introduces opportunity for error. Like a game of whispers, key details almost always get lost in translation. A staff member could misunderstand the customers needs or misreads symbols and acronyms. The problem is that the system relies entirely on a person, who may be new, to deliver safety-critical information from a document they may not fully understand themselves.

Two different scenarios. The same underlying issue: the document wasn't built to communicate directly with the customer.

What the spreadsheet can't do

Even in its best form, the spreadsheet that’s kept on premises can't be accessed by the customer when they're deciding where to book.

It's a back-office document that solves a different problem than the one that actually matters: giving customers the information they need, in the place and at the time they need it.

What legal protection it actually provides

There's sometimes an assumption that having a spreadsheet provides legal protection – that documentation of allergen information, however imperfect, shows the restaurant made an effort.

The legal requirement under UK food law isn't to have a document. It's to provide accurate allergen information to customers. A document that's out of date, that staff can't reliably access during service, and that doesn't reach customers before they make decisions, provides limited protection when something goes wrong. Liability sits with the business owner regardless.

Having a document isn't the same as having a system that’s genuinely helpful.