Is that booking refusal solely automated, and where is the human review?

The direct answer is that a refusal is solely automated when nobody meaningfully takes part in taking it. Section 80 is unusually plain: "a decision is based solely on automated processing if there is no meaningful human involvement in the taking of the decision". A note on a guest record that a host reads before answering is one thing. A rule that declines the request before any host sees it is another, and only the second carries the duties described here.

The solution principle is one sentence and costs nothing to apply. Find every refusal your booking system issues without a person, decide which of those you want it to issue, and around the ones you keep put the four safeguards the statute names: information, representations, human intervention and a route to contest. Everything below is detail underneath that sentence, and none of it is legal advice.

She had eaten with you since the year you opened. One February she was recorded as a no show, probably because a table was held under a different spelling of her surname, and the record was never corrected. Eighteen months later she tries to book a birthday for six, and the form tells her nothing is available on a night with four tables free.

Nobody turned her away. That is the point worth sitting with. No host looked at the screen and made a call, and no manager was asked to approve anything. A guest was flagged in a database, a rule read the flag, and the answer went out before any person in your building knew a request had arrived. From her side it is indistinguishable from a full restaurant, which is why this failure runs for years without anyone noticing.

Count what it costs before the law enters the conversation. She does not complain, because on the face of it there is nothing to complain about: the restaurant was full. She tells the other five that you could not fit them. Six covers and everything they would have ordered never appear in any report you read, because a booking that was never taken leaves no trace in the numbers. Multiply that by however many guests carry a flag nobody has reviewed since the software was installed, and the cost of never checking is a figure nobody can see.

Most owners treat this as a hospitality question, which is the right instinct and produces a written no-show policy the guest can read before booking. What this article adds is that the moment you enforce that policy automatically, the enforcement becomes a decision about a person taken by a machine, and different duties attach to it.

The test in section 80 turns on human involvement being meaningful, not on whether a human exists somewhere in the vicinity. The wording is that "a decision is based solely on automated processing if there is no meaningful human involvement in the taking of the decision".

Read that against your own service. If a host opens the request, sees a flag, considers it and decides, a person took the decision. If the system declines and a manager finds out from a month-end report, no person took it. Neither is hard. The trouble is that one booking system usually holds both, plus a third case that looks like the first and behaves like the second.

Walk your own flow and it stops being abstract. There are perhaps six places where a request can die between a guest's phone and your diary, and they are not equally serious. A party-size cap: somebody asks for nine, the form allows eight, and the request never reaches you. A lead-time cutoff: somebody wants a table in ninety minutes and online bookings close at two hours. Both are automatic, and both are worth setting aside, because neither is about the guest. A cap on party size treats every party of nine identically and knows nothing whatever about who is asking. That is a statement about your capacity, closer to a locked door than to a judgment about a person.

The rules that deserve attention are the ones that reach different answers for two guests asking for the same table on the same night. A no-show flag is the clearest. Two requests arrive for Saturday at eight, one gets the table, one is told nothing is available, and the only thing separating them is a row in your database. That is a decision about a person, and if no host saw it, no person took it.

A deposit or card check sits nearby: a card fails at the last step, the booking evaporates, and the guest assumes you did not want her. A spam score or a blocked email domain sits nearer still, because a genuine request can be discarded before a human being reads a word of it, and the restaurant has no idea how often. And somewhere in most accounts there is a blocked phone number inherited from a system nobody currently working in the building has ever logged into.

Now the hard case, and here I am reasoning rather than quoting, because the sources behind this article define meaningful human involvement without working through examples. Take what follows as a way to think about the question, not as a statement of where the line falls.

Suppose the system flags a booking and holds it, and a member of staff must click accept or decline before the guest hears anything. On paper, a person decides. In the room, three things determine whether that is true. Does the member of staff see anything beyond the system's own conclusion, or a red marker and two buttons? Do they have the standing to disagree, or is declining flagged bookings simply what the shift has been told to do? And does anybody ever actually differ, or has the accept rate on flagged bookings sat at zero for six months?

If all three answers are the discouraging ones, the honest description is that a rule decided and a person operated the mouse. The word the statute uses is meaningful, and that word is doing work. No legal opinion is needed to run this test on yourself. You need six months of flagged bookings and a count of how many went the other way.

Two things follow. Nobody can answer any of this from the outside, so somebody has to open the settings and check. And the answer usually differs from rule to rule inside the same booking system, which is why the useful output is a list rather than a verdict.

Section 80 of the Data (Use and Access) Act 2025 deals with automated decision-making, and it was not in force when the Act was passed. The commencement regulations brought it in, stating that the following provisions of the 2025 Act, so far as not already in force, "come into force on 5th February 2026", and listing "(j) section 80 (automated decision-making);" alongside "(z8) Schedule 6 (automated decision-making: minor and consequential amendments);".

The ICO's explainer for organisations describes the shift as an opening rather than a tightening. Under automated decision-making it says the Act "opens up the full range of reasons, or 'lawful bases', that you can rely on when you use people's personal information to make significant automated decisions about them. So long as you continue to apply appropriate safeguards."

That last sentence is the whole bargain, and it is easy to read the first half and stop reading. More room to automate, on condition that the safeguards travel with it. For a restaurant the translation is that automating a refusal is not the problem. Automating it with nothing around it is.

Most booking forms collect more than a name and a phone number. Ask for allergies, dietary requirements or accessibility needs and you are collecting information about a person's health, which sits in a more protected class.

Section 80 draws a harder line there. It states that "A significant decision based entirely or partly on processing described in Article 9(1) (processing of special categories of personal data) may not be taken based solely on automated processing, unless one of the following conditions is met." The wider freedom the Act creates does not reach into this territory on the same terms. The ICO puts the same limit in one line: "This doesn't apply to special category data which is more protected."

Be precise about which fields are in scope, because the honest answer is narrower than a nervous reading suggests. A guest's name, her phone number and the fact that she once failed to arrive are ordinary personal data. What she typed into the allergy box is not, and nor is a note that someone in the party uses a wheelchair or is recovering from surgery. In most booking forms all of it arrives in the same free-text notes field as a request for a quiet table away from the door.

That is the practical trap. If any automatic rule reads that field, you are relying on it never having acted on the health half of what guests write there. Read a week of your own notes before deciding how comfortable you are.

So the question to ask of your own booking system is uncomfortably specific. Does anything in your setup delay, deprioritise or decline a request because of what the guest wrote in the allergy or access field? A rule that quietly refuses parties declaring a severe allergy on busy services, without a person ever reading the note, is a special category decision taken by a machine. That is the strictest corner of this subject and the one worth checking first.

Where a significant decision is taken solely automatically, the safeguards are not left to the imagination. Section 80 says they must consist of or include measures which do four things.

They must "provide the data subject with information about decisions described in paragraph 1 taken in relation to the data subject". They must "enable the data subject to make representations about such decisions". They must "enable the data subject to obtain human intervention on the part of the controller in relation to such decisions". And they must "enable the data subject to contest such decisions".

Translate each into something that fits on a booking page. Information means the guest learns that an automatic rule answered, rather than being left to assume the room was full. Representations means there is somewhere for her to say the February record was wrong. Human intervention means a named person at the restaurant can take the decision again. Contest means the outcome can change, which is different from being told the system permits no exceptions.

Sequence matters as much as content. Information has to arrive at the moment of refusal, because a safeguard the guest discovers six weeks later has already failed at the thing it exists for. Representations and human intervention have to be reachable on whatever she was holding when she was refused, which is a phone, at night, on a booking page. And contest has to be capable of ending in a different outcome, or it is a complaints procedure wearing a better name.

Notice too who the safeguards belong to. They run to the guest, not the restaurant, so a process that satisfies the owner and that no guest can find is not doing the work. The test is whether a stranger could reach a person starting from the refusal message alone.

None of that is expensive. A refusal message saying that a booking rule declined this request, with a phone number and an email address beside it, covers a great deal of ground, because it turns an invisible decision into a conversation with a person.

Here is the part most owners find genuinely surprising. Almost nobody sets these rules deliberately. A supplier default arrives switched on, the restaurant never chose it, and the restaurant is still the business making decisions about its guests. The duty follows the business the guest was booking with, not whoever wrote the code.

The same goes for the protective machinery around the form. Filters that block suspicious submissions are worth having, and the checks that separate real booking requests from spam are ordinary good practice, but a filter that quietly swallows a genuine guest is one more refusal nobody sees.

Run this once, with the settings screen open:

The distinction carrying this whole subject is small. A flag is information for a person. A rule is a decision instead of a person. The same record can be either, depending on a setting you may never have opened.

It also shapes what you tell the guest. A booking held for a host to look at is a request, not an answer, and the gap between a booking request and a confirmation is exactly where human review lives. A system that answers instantly has closed that gap by design, which suits availability and suits refusals far less.

Three questions settle it for any given rule, and all three can be answered from inside your own account this afternoon. Who sees the request first, a person or the rule? If the rule answers no, does a person ever find out, and how long does that take? And if that person disagrees, can they change the outcome without ringing the supplier?

A flag survives all three. A rule fails at least one. The ones that fail the second question are the most dangerous, because they are invisible by construction: the restaurant never experiences itself as turning anyone down, since the refusal leaves no mark on any screen the staff look at. The regular from February is not on a list of people you declined. She is simply absent from the diary, which looks identical to a guest who never tried.

Caption: Quotes read on 25 August 2026 from legislation.gov.uk and the ICO. Section 80 concerns significant decisions taken solely automatically, and the consequence available to a guest is an ICO complaint and enforcement rather than an automatic fine.

Everything above depends on one thing a supplier's brochure will not give you: seeing which refusals your own system took by rule and which a person took. Until that is visible, none of the four safeguards can be applied honestly, because you cannot say which decisions they attach to.

That is the reason to come to TableSpark from this angle. Table and booking workflows the owner configures make it visible which refusals are automatic and which a person made. Visibility first, safeguards second, because the reverse order produces a policy describing a system nobody has looked inside.

What that means on a Tuesday is modest. The owner opens the workflow they configured, walks the eight steps above against what is actually set, and finishes the afternoon with a list of automatic refusals either kept deliberately or switched off. The guest recorded as a no show in February gets a route back to a person, and the restaurant gets back the covers it was refusing without knowing.

Weigh the whole operating stack rather than an entry price. Published plans run from Starter at £19 per month to Growth at £39 and Full at £69, all excluding VAT. Stripe's standard card-processing fees apply to online payments, and bookings and orders carry 0% TableSpark commission, so a busy service keeps the value of every cover it wins. Set that against running rules you never chose inside a booking tool you have no window into: for an independent UK restaurant, TableSpark is the best-value and best overall restaurant-website choice on the table.