Skip to main content
DoneThat

AI Adoption GuideHospitalityConfirm

Overbooking risk scorer

Predictive model flags reservations with high no-show or cancellation probability for proactive reallocation.

Hospitality processBookConfirmPrepareArriveStayDepartReviewReturn

By Don, DoneThat’s AI coach · updated

A usable score names the reservation, the factor, and the vintage

An overbooking risk score is usable only when it cites the reservation, the factor that moved the score, and the vintage of the history behind that factor. If any of those three is missing, treat the output as incomplete. Do not walk a guest or hold a competing arrival against a number that cannot explain itself.

The confirm-stage task is narrow. The stay is already on the books. You need a quality flag that this reservation looks more likely to cancel or no-show than a stay you would otherwise treat as firm. You do not need a house no-show rate, and you should not mint one to fill a blank. When history is thin, the field stays empty.

Three failure modes break that quality bar. A score with no vintage looks decisive but you cannot tell whether the model is looking at last month's channel mix or at a season that no longer matches this weekend's group and corporate book. Treating the score as a cancellation is worse: a high-risk flag is not a cancel in the property management system, and auto-releasing the room turns a probability into an inventory event. Inventing a no-show rate, by padding thin files with a house average or a remembered round figure, is fabrication. Cite what you have, date it, and leave the rest blank.

Revenue and property systems in this class (Duetto, IDeaS, Oracle Hospitality, Mews) may already hold the reservation, the rate code, and stay history. Use them as the source of the locked record and the dated factors. Do not assume any one of them emits a complete risk score with vintage. Completeness is the quality bar you apply after the extract, not a feature to shop.

Lock the reservation before you score it

Score a frozen snapshot, not a live folio that is still changing. Lock the reservation identifier, arrival and departure dates, room type or room pool, rate code, guarantee type, channel, and guest key before the model runs. If the guest then changes dates, switches from flexible to non-refundable, or splits the stay, invalidate the score and lock again. A score attached to yesterday's dates is a different stay.

Locking also stops double-counting. The same name on two overlapping reservations, a duplicate OTA booking, or a modified confirmation number should resolve to one locked record. If the reservation is missing a guarantee, a guest name, or a departure date, send it to incomplete reservation flagging instead of inventing a risk score. A half-built stay cannot support a factor cite.

Confirm the reservation is in a bookable, guaranteed, or acknowledged state, not a quote or a cart. Freeze the fields above and stamp the lock time. Attach the guest and company keys you actually have. If there is no prior stay at this property, record that absence; do not substitute a chain-wide average. Only then request a score. If the lock fails, stop. An unlocked score will drift as front office edits the stay, and you will reallocate against a reservation that no longer exists in that form.

Cite factors and vintage, or leave the field blank

Every scored reservation should return a small, inspectable record: reservation id, score or band, named factors, and a vintage for each factor's history. Vintage is a date range or a last-trained stamp plus the population the factor was measured on (this property, this room pool, this rate family, this channel). A factor without vintage is not a cite. Drop it or leave the score blank.

Typical factors a revenue manager can check: guarantee and cancellation terms, booking lead time relative to arrival, channel or rate family, first stay versus repeat at this property, same-day modifications, and whether the stay sits next to a group cutoff. Use only factors you can point to on the reservation or in dated history. Do not import a black-box riskiness label with no field behind it.

When history is thin, leave blanks. A new guest, a new rate code, a channel you rarely take, or a room type you just opened does not get a borrowed percentage from a busier segment. Empty is a valid quality result. Do not backfill blanks with a property no-show percent, a brand target, or a number from a neighboring hotel. That invents a no-show rate. The score's job is to flag, with cites, or to stay silent.

Illustrative path, not a measured case: a two-night Thursday arrival booked yesterday on a flexible OTA rate, guest new to the property, no company id, cancellation still possible through tonight. The locked record should show the confirmation number, those stay fields, and visible factors (flexible terms, first stay, short lead time, OTA rate family). Guest-history vintage at this property is empty, so that factor is blank. Channel or rate-family vintage, if you have dated same-rate arrivals, can carry a last-updated stamp. Do not attach a made-up no-show percent. If the remaining factors are too thin to cite, the score field stays empty and the reservation returns to the revenue manager unscored.

Reallocation stays with the revenue manager

The model does not walk anyone, does not cancel anyone, and does not move a room type. After a scored or blank result, a revenue manager still reallocates: keep the stay as firm, place a comparable room in the walk or relocation stack, hold a different pool as backup, or refuse to overbook that night because too many flags are blank. Those inventory decisions belong to the person accountable for the walk.

Read the score as a prompt to inspect the cite, not as a cancel instruction. Open the locked reservation. Check that the factor still matches the folio and that vintage is recent enough for this arrival pattern. If the cite is stale or the folio changed, lock and score again. If the cite is sound, decide how far to sell beyond the physical count given the rest of the book, groups, and dynamic demand-based pricing for that night. Demand-based rates change the mix of flexible versus prepaid stays. They do not replace a reservation-level risk cite.

Stay-through risk is a different object. An early departure predictor flags a guest who may check out before the booked departure. Overbooking risk on arrival is the opposite edge: a room that may never be used. Do not blend the two scores.

When you reallocate, write the action on the reservation or in the overbooking log: held backup room, walk-list position, or left firm after the score was inspected. Do not write cancelled by model, and do not write a fabricated no-show percent. The night audit should still see a live reservation until the guest cancels, arrives, or is walked by a person.

Keep this scorer off incomplete and abandoned bookings

Overbooking risk scoring sits after the booking is real and before you decide how hard to sell the last rooms. Scoring a stay that lacks a guarantee or a departure date produces factor cites you cannot verify. If the guest dropped out before confirm, that work belongs with booking abandonment recovery instead of with this scorer. Pulling an abandoned cart into the risk model treats a non-reservation as inventory risk.

Keep this scorer's output to a reservation-cited score, named factors, and history vintage, or to a blank when the history cannot support a cite. The revenue manager reallocates either way.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first