Early departure predictor

The only output worth putting on a desk is a quality flag: this in-house guest may leave before the booked departure date, because of this cited behavior, scored against history of this vintage. The flag does not check anyone out. It does not change reservation status. It does not invent a no-show percent for the night or the segment.

Revenue and front-office managers already reallocate when a stay ends early. The score exists to start that conversation while the stay is still in-house. If you treat the flag as a completed checkout, you can sell the room twice, strand luggage, and train the desk to obey a badge instead of the folio.

No-shows are arrivals that never registered. Early departure is an in-house stay that may consume fewer nights than booked. Those are different inventory objects. Printing a made-up no-show percent beside an early-out flag makes the ticket look precise and makes the night unsafe to sell.

In-house stay records usually sit in a property management system, including platforms in the Oracle Hospitality and Mews class. Remaining-demand and rate decisions usually sit in a revenue management system, including platforms in the Duetto and IDeaS class. Do not assume any of them will, or should, auto-checkout from a model score. The desk reads the flag, then moves inventory with existing controls.

When a flagged room might be offered again the same day, read it next to an overbooking risk scorer so a possible early out is not treated as guaranteed capacity.

Score a frozen picture of the stay, not a folio that is still moving. Lock means you capture the booked departure date, room type, rate plan, any loyalty identifiers you are allowed to use, and the in-stay timestamps you will cite. You then refuse to rescore against a later room move, a late charge, or a partial checkout until a person releases the lock.

Without a lock, a guest who posts a minibar charge at 16:00 can look quiet at 14:00 and ordinary at 16:30. The flag flips, housekeeping is pulled off a stayover, and the queue stops being trusted. Lock also stops two systems from racing: the PMS still owns the legal stay; the scorer owns a snapshot.

The lock is how you keep auto-checkout out of the pipeline. The scored object is a copy. Checkout remains a desk or kiosk event. If a workflow offers a predicted-checkout status, do not map it to actual checkout.

Record when the lock was taken. That timestamp is the as-of time of the stay snapshot. It is not the history vintage. Both belong on the ticket so a manager knows whether the picture is from this morning.

A flag with no cite is a rumor. A flag with no vintage is a rumor with a number on it. Both show up as a confident badge and an empty explanation. Reject them. The ticket must show at least one in-stay behavior a night auditor can check, plus the window of comparable stays that defined unusual.

Desk-checkable signals include unused incidentals after the first night, skipped breakfast on a rate that includes it, no outlet covers when this booking type usually produces them, a late-checkout request that was later withdrawn, or a sudden request for a printed folio mid-stay. You do not need every signal. You need the ones that fired, written so someone can open the stay and see the same facts.

History vintage is the dated cohort behind the comparison: this property, this room type or rate family, this season or stay-length band, through a named end date. "Based on our data" is not a vintage. "Guests like this" is not a vintage. If the cohort is too old, say so, or leave the flag blank. History that straddles a renovation or a rate-strategy change will flag guests who travel differently now.

Do not translate the score into a no-show percent. If the revenue system needs a demand adjustment, pass a qualitative early-out hint or a manager-confirmed released night, not a fabricated arrival probability.

Complaint patterns can look like early-out patterns. Before you treat silence plus a folio print as packing, check whether a mid-stay complaint predictor already opened a recovery path. A guest waiting on a room move is not a guest who has left.

On a Thursday afternoon, a revenue manager opens a flagged king stay booked through Saturday. The ticket cites two checkable facts: housekeeping was declined after night one, and included breakfast was unused both mornings. The vintage line names comparable in-house stays at this property for this room type, through last winter's season close. The manager does not change the reservation. They call the room. The guest says they need to leave tonight. Only after that confirmation does the desk post checkout and release Saturday. Housekeeping is asked for a same-day turn. The waitlist is offered the room. The model never acted as checkout clerk, and the ticket never printed a no-show percent. On another Thursday the guest is still in-house. The flag stays a flag.

Empty is a valid quality outcome. A one-night stay with no incidentals file, a walk-in with no prior folio, a group room whose charges sit on a master account, or a stay whose comparable history fails the vintage rule should return a blank, not a low-confidence decoration.

Thin is not the same as contradictory. Thin means you cannot name a behavior and a vintage. Contradictory means you can name both and they disagree, for example a spa booking plus a folio-print request. Keep that stay locked and unflagged, or send it to a person with both cites visible. Do not average them into a medium badge.

Blank also stops over-eager reallocation. If every in-house room is required to show a score, someone will fill the blank with a guess. That guess is an invented early out, which is the same error as inventing a no-show percent: you are manufacturing a night you have not earned.

Put the blank policy on the ticket: no flag, insufficient cited behavior or insufficient history vintage. Night audit should not complete those rows.

The manager still reallocates. Reallocation means offering the remaining night to a waitlist, a walk-in, a stayover extension, or a same-day channel, using inventory controls you already trust.

Confirmation can be a phone call, a guest message, or a request at the desk. Until then the stay is in-house. Do not pre-assign the room to a new arrival in a way that cannot be reversed. Do not tell housekeeping the room is vacant. Do not let the revenue system treat the night as definitely sold twice.

Once the guest is actually checked out, the remaining night is real inventory. That is when a housekeeping schedule optimizer should see a same-day vacant, and when a departure time optimizer should stop planning a late-day exit for that room. Predicted early departure is not a departure time. Mixing them puts a vacant-ready clock on a room that still has luggage.

If the guest is not leaving early, retire the flag for that stay night. Do not leave it blinking into the evening. A retired flag that still shows the original cite and vintage is useful for later review. A sticky flag the desk ignored is how people start auto-acting to clear the queue.

Enter the confirmed release in the PMS or RMS you already run, including systems in the Oracle Hospitality, Mews, Duetto, and IDeaS class. Put the human decision in the system of record. Keep the model ticket attached as the reason you called, not as the reason the room is empty.