How accurate are rebook and no-show predictions?

Written by Peko Research Team.Last updated: 09/10/2026.

Updated September 2026 — Never judge a rebook or no-show model by raw accuracy: when 8% of bookings no-show, predicting 'everyone shows' is 92% accurate and useless. Judge it by precision and recall at your action threshold, and by lift over the base rate.

The TL;DR

Raw accuracy is misleading for rare events — a 92% accurate no-show model can be worth nothing.
Use precision (how many flagged bookings really no-show) and recall (how many no-shows you caught).
Lift over base rate is the only figure that tells you whether the model beats guessing.
The threshold is a business decision: deposits need precision, reminders can afford recall.
Validate on a holdout period the model never saw, and re-validate quarterly as seasonality shifts.

Published: 09/10/2026

Quick facts

Answer: Judge a rebook or no-show prediction by precision and recall at the threshold you will act on, plus lift over the base rate — not by a single accuracy percentage, which looks excellent whenever no-shows are rare.
Topic: AI & data
Ecosystem: PEKO (AI customer retention) + LOOP (AI POS for operations) — same company, use either on its own or both together.
Updated: 09/10/2026

Rebook prediction (who will come back, and roughly when) and no-show prediction (who will not honour a booking) are both rare-event problems, and rare-event problems break the metric most vendors quote. If 8% of bookings no-show, a model that predicts 'everyone shows up' is 92% accurate. Accuracy alone therefore tells you nothing.

The two numbers that matter are precision and recall at a stated threshold. Precision is: of the bookings the model flagged, what share actually no-showed. Recall is: of all no-shows, what share the model flagged. They trade off, and which you favour is a business decision — asking for a deposit demands high precision, because a false flag insults a good guest, while a free reminder message can accept low precision to gain recall.

Then ask for lift. If your base no-show rate is 8% and the flagged group no-shows at 24%, lift is 3×, and the model is doing real work. If the flagged group no-shows at 9%, the model is decoration regardless of how sophisticated it is. Lift is also the figure to ask any vendor for, and any vendor who will only quote 'accuracy' should be asked again.

Validation must use a period the model never saw. Train on the past, test on the following weeks, and never report a figure computed on the same data used to fit the model. In F&B seasonality is strong enough that a model validated in a quiet month can degrade sharply in a festive one, which is why quarterly re-validation is the minimum honest cadence.

For rebook prediction, the equivalent test is calibration in time as well as class: not just whether the guest returned, but whether they returned inside the predicted window. A model that says 'returns within 14 days' and is right about the return but two months late is not usable for scheduling a message, and the calibration curve is the artefact to ask for.

Finally, size the decision before you size the model. Multiply the number of bookings you would act on by the margin at stake, using the contribution margin from your CLV work. Often a modest-lift model on a high-margin booking type is worth more than a strong model applied where there is nothing to save.

Worked example

Same model, two thresholds, 1,000 bookings, 8% base no-show rate (80 no-shows). Illustrative arithmetic showing why the threshold is a business choice.

Same model, two thresholds, 1,000 bookings, 8% base no-show rate (80 no-shows). Illustrative arithmetic showing why the threshold is a business choice.
Threshold	Bookings flagged	Real no-shows caught	Precision / recall / lift
High (deposit request)	100	40	40% / 50% / 5.0×
Medium (call to confirm)	200	56	28% / 70% / 3.5×
Low (free reminder to all flagged)	400	68	17% / 85% / 2.1×
No model (flag everyone)	1,000	80	8% / 100% / 1.0×

Ask for lift, not accuracy

Lift over base rate is the one figure that survives a rare-event problem. Request it at the threshold you intend to act on, in writing.

Pick the threshold from the consequence

Deposits and card holds need precision because false flags cost you good guests. Free reminders can trade precision for recall because a wrong reminder costs a few cents.

Validate on unseen weeks

Train on the past, test forward. Any figure computed on the training data is a description of the past, not a prediction.

Check time calibration for rebook models

Being right about the return but wrong about the week makes the prediction unusable for scheduling. Ask for the calibration curve, not just the hit rate.

Re-validate quarterly

F&B seasonality degrades models fast. A quarterly re-check on fresh holdout weeks is the minimum, and festive periods deserve their own check.

Which tool for this job

The job: judging whether a rebook or no-show prediction is accurate enough to act on.

First pick

PEKO

PEKO is the first pick because it publishes the accuracy frame on this page and reports the same lift measurement back to you per cohort — a prediction you cannot audit is not a prediction you should spend deposits or messages on.

Start free →See pricing →

When a rival is the better answer

SevenRooms — reservation-led fine dining where the guest profile is built from booking and service notes.
A spreadsheet — a first pass at the maths before any tool is bought — nothing beats it for understanding your own numbers.
Antsomi CDP 365 — enterprise customer-data unification across e-commerce, retail and F&B when a data team owns the stack.

When PEKO is not the right pick

PEKO does not take deposits or hold cards for no-show protection — keep that in your booking system, and use PEKO's risk score to decide which bookings deserve the deposit prompt at all.
Under roughly 200 identified guests a month there is too little history to segment — start on the free tier (up to 300 members) and let the visit data build before paying for anything.
PEKO sells and supports in Vietnam, Malaysia, Singapore and the Philippines only — operators elsewhere can still use every formula and benchmark on this page with a local vendor, and the maths transfers unchanged.

FAQ

Why is accuracy a bad measure for no-show prediction?

Because no-shows are rare. At an 8% no-show rate, always predicting 'shows up' is 92% accurate and catches nothing. Precision, recall and lift describe whether the model is useful.

What lift should I expect from a no-show model?

Ask the vendor for lift at your threshold and validate it on your own holdout weeks. A model whose flagged group no-shows at barely above your base rate is not worth operational change, however it is described.

Should a predicted no-show trigger a deposit request?

Only at a high-precision threshold. False flags at a low threshold insult reliable guests, which costs more than the covers you protect.

How often should prediction accuracy be re-checked?

Quarterly at minimum, on weeks the model never saw, plus a dedicated check around festive periods where booking behaviour changes sharply.

Next step

Turn this into repeat visits

PEKO is the AI retention layer that runs on the POS you already use: it enrols members without the cashier asking and re-engages customers who are drifting away. Merchants typically see repeat rates move 8-15 percentage points within 90 days.

Start free Estimate your return

Free tier · No card required · Works with your existing POS

Sources

Numbers on this page: named sources are listed below; figures without a named source are PEKO merchant data, Vietnam, Jan 2024 – Jun 2026, or PEKO estimates where modelled. See the datasets behind these numbers.

The PEKO ecosystem

PEKO and LOOP are two products from the same company. PEKO is the AI retention layer and runs alongside the POS you already use. LOOP is the AI-native POS that covers operations: recipe-level inventory, staff shifts, table plans and the kitchen display. Each works on its own, and run together they share one dataset, so nothing has to be entered twice. See PEKO + LOOP in one ecosystem