Why no-show prediction is the hardest interesting problem in hospitality.

Every restaurant operator I've talked to in the last decade has a no-show story. The Saturday night they held a six-top for forty-five minutes. The party of twelve that confirmed twice and never came. The Valentine's Day where the rebookings cascaded so badly they comped the entire dining room of guests who did show up just to keep the night from collapsing.

These stories aren't anomalies. They're the texture of running a restaurant. Most operators have built scar tissue around them (overbooking strategies, deposit policies, automated reminder cascades) and most operators will tell you, if you ask honestly, that the scar tissue isn't really working.

Which is fascinating, because no-show prediction is, on its face, an obvious machine learning problem. You have historical reservation data. You have outcomes (showed / didn't show). You have features (party size, time of day, day of week, lead time, channel, customer history, weather, the local concert schedule, whether the kid's high school playoff game is at 7). It's a clean supervised learning setup. Any decent data scientist should be able to fit a model and ship it.

So why hasn't anyone really solved this?

I've been thinking about this problem for a long time, both inside operating companies and as a builder. I have a theory. Actually, I have six theories. Each one is a reason why the obvious solution isn't actually obvious, and together they explain why no-show prediction sits at the intersection of trivial to start and brutal to finish. If you understand the six, you understand most of what's broken in hospitality data right now.

---

One. The data is small.

The first thing that catches every data scientist by surprise: a single restaurant generates almost no data.

A 120-seat restaurant doing two turns a night, six nights a week, with an average party of three, is processing about 24,000 reservations a year. That sounds like a lot until you realize you need to partition that data by daypart, by season, by party size, by reservation channel, by lead time. By the time you've sliced it into the segments that actually matter operationally, you're looking at hundreds of reservations per cell, not thousands.

Modeling at that scale is hard. The variance is enormous. The signal-to-noise ratio is bad. Most off-the-shelf ML approaches that assume "lots of clean data" don't work. You're closer to old-school actuarial modeling than to modern deep learning. And that's one restaurant, multi-unit operators have the opposite problem of too much data with massive heterogeneity across locations.

The data is small until it isn't, and then it's a different problem entirely.

Two. The labels are dirty.

This is the one that breaks most projects.

In theory, you know who showed up and who didn't. In practice, your data system records "no-show" for a whole pile of things that aren't actually no-shows:

• Guests who cancelled but the host forgot to update the reservation
• Walk-ins seated at the reserved table without rebadging
• Reservations that got merged or split at the door
• Late arrivals (45+ minutes) that got rebooked as walk-ins
• Hostess error during the rush

I've seen no-show rates reported as 18% in one POS system and 4% in another for the same restaurant. The difference wasn't the customers. It was the data hygiene.

If you can't trust your labels, you can't train a model. And nobody is going to fix the data hygiene for you, fixing it requires changing host behavior during the dinner rush, which is not where operators have the bandwidth for process discipline. So you either accept dirty labels and ship a flawed model, or you spend six months cleaning data and shipping nothing.

Most teams pick door number one. Most models are flawed.

Three. The cost asymmetry is brutal.

False positives and false negatives are not equal.

If your model predicts a no-show and you're wrong, meaning the guest actually shows up and you've already given the seat away, that's a catastrophic customer experience. A confirmed reservation, on time, denied entry. Online reviews. Public complaints. Possible refunds. Definite churn.

If your model predicts a show and you're wrong, meaning the guest no-shows, that's the current state of pain, which the operator is already absorbing. It hurts, but it's the baseline.

This means the model has to be dramatically more accurate at predicting no-shows than the natural cost asymmetry would suggest. A 70% accurate model is mathematically valuable but operationally toxic, because the 30% you're wrong on are the most visible failures the restaurant has. Operators won't deploy it. They shouldn't deploy it.

Solving this requires either much better models or much smarter interventions, interventions that don't require certainty to be valuable. Most teams underestimate this gap.

Four. The interventions are political.

Even if you have a perfect model, the interventions are hard.

Charging a deposit to high-risk reservations changes the brand. Calling guests to confirm changes the contact center workload. Holding the seat shorter cuts into revenue when the guest does arrive. Routing high-risk reservations to specific time slots changes the floor plan dynamics.

Every intervention touches a function the data team doesn't own. Operations doesn't want the workflow change. Marketing doesn't want the friction. Hosts don't want the script change. The GM doesn't want the political exposure.

The intervention is where the value lives, and the intervention is where the cross-functional politics kill the project. Most no-show projects die at the intervention step, not the modeling step. Which means the model, the part the data team worked on for six months, never actually gets to bend behavior. It just sits in a dashboard.

Five. The feedback loop is delayed.

When you do ship an intervention, you don't find out for weeks whether it worked.

The reservation that gets a friction-added deposit today either holds or doesn't, but the system-level effect, does this change overall no-show rate, does it change overall booking volume, does it change guest demographics, takes a quarter to read. Maybe two quarters once you account for seasonal noise.

In machine learning terms, the feedback loop is so slow that the model is essentially flying blind during the period when you most need to be iterating. By the time you have enough data to know the intervention worked, the season has changed, the menu has changed, the host has rotated, and the data you have is no longer representative of the world you're now operating in.

This is the hidden killer. Most ML problems benefit from fast feedback loops. No-show prediction has the slowest meaningful feedback loop of almost any commercial ML problem I've worked on.

Six. The platform incentives are wrong.

The biggest reservation platforms (OpenTable, Resy, Tock, SevenRooms) sit on the largest no-show datasets in the industry. They could solve this. They have the data. They have the engineering. They have the models.

But they don't, because they don't want to.

The reservation platforms make money on reservation volume, deposit transactions, and SaaS subscriptions. None of those revenue streams are directly improved by reducing no-shows. Reducing no-shows improves the operator's economics, but the platform's economics are basically agnostic to it. So no-show prediction sits in the same place it has sat for fifteen years, vaguely mentioned in feature docs, never seriously productized.

This is the most interesting problem in hospitality data because the people best positioned to solve it have no commercial reason to. Which leaves a gap. A gap a smaller, focused team could fill, if they were patient enough to deal with the other five problems above.

---

So that's why it's hard.

Small data. Dirty labels. Asymmetric costs. Political interventions. Delayed feedback. Misaligned platform incentives.

Any one of these would be a meaningful challenge. All six together explain why no-show prediction has resisted thirty years of incremental improvement, and why operators have given up on the idea that anyone is going to fix it for them.

I'm building Coverly because I think these problems are solvable, not easy, but solvable, if you approach them with the patience and the operator empathy they require. The data is small but rich. The labels are dirty but improvable. The cost asymmetry is real but reframeable. The interventions are political but negotiable. The feedback loop is slow but trustable. The platforms are misaligned but bypassable.

Six fights, not one. That's the work.