Booking abandonment recovery

A recovery candidate is worth a human send only when it cites two things: the abandoned session fields, and the intent factor that made this drop-off unusual. Session fields mean the stay dates, room type or occupancy mix, rate plan if one was on the cart, and the last checkout step the guest reached. The intent factor is a named reason you can point to in that same session, such as a return to the same dates, a completed guest-detail form, or a stop on the payment step after a room was held. A draft that asks someone to come back and book without those cites is not a candidate. It is a generic chase.

The person who still sends the message is the revenue or e-commerce manager. Scoring does not send mail, SMS, or chat. Flagging a session as high-intent is not proof that a recovery went out, and it is not a conversion rate. If you cannot name the cart and the factor, leave the output empty.

Guest-messaging platforms and property or booking systems in the same class as Asksuite, HiJiffy, Oracle Hospitality, and Mews may store the session, the profile, or the channel. Treat them as the system of record and the send path, not as a substitute for an inspectable score. None of those products decides, by itself, whether this abandon deserves a personal note. Your rule does.

Start by loading the abandoned session, not by writing a greeting. Pull the booking-engine or CRS event for that visit: arrival and departure, adults and children, room code or description, rate plan or rate code if present, promo or corporate code if present, timestamps for each checkout step, and whether a room was selected. If the guest authenticated or left an email, attach that identifier. If they were mid-conversation with a conversational booking agent, load the last confirmed stay parameters from the transcript the same way you would from a form cart. Do not invent a room type the guest never selected.

Score only with fields you can cite. High-intent is a claim about this session, not a personality label. A guest segment intent classifier can sit upstream when you already have a stable guest or account, but the recovery score still has to quote the abandon itself. If the classifier labels a corporate account and the cart is empty, you do not have a recovery candidate. You have a segment with no cart cite.

Write the score as a short record the manager can audit: the session identifier, the cited fields, the intent factor in one sentence, and a recommended channel that already exists for that guest. Do not attach a predicted conversion percentage. You do not have one from this flag. If payment failed with a processor code, cite the code and the step. That is a technical retry, which may still be a candidate, but only with that cite. If the guest closed the page during an authentication challenge, say that. Do not call it low interest.

An unfinished booking visit is common. That alone is not a recovery. A single look at the calendar, a bounce after the first rate table, a room list with no selection, or a session that never reached guest details is not, by itself, worth a send. Empty is the correct output. Filling the queue because a session ended trains the team to ignore every row.

Leave empty when you cannot cite a cart, when the last step is still discovery, or when the only signal is that the guest left. Leave empty when the dates or occupancy cannot be booked as entered, such as a child age the rate plan rejects or a closed arrival, and the guest never corrected them. Leave empty when the guest cleared the cart or used an explicit cancel control. Recovery is for a high-intent interruption, not for every unfinished look.

Do not rescue emptiness by pasting a new price. Dynamic demand-based pricing may have moved the rate after the session ended. If you mention rate, cite the rate the guest actually saw and the time it was shown. A fresh best available rate with no session cite is a pricing decision, not abandonment recovery.

A leisure guest looking at a city stay opens two weekend nights, two adults, one connecting room type, a flexible rate, and completes guest details including an email. They reach the payment step, remain there long enough that the engine logs a hold, then the session ends without a booking. The same arrival dates appear earlier the same day on a shorter visit that stopped at the room list.

That session is a candidate because you can cite the cart (dates, occupancy, room type, flexible rate, payment step, email) and you can cite the intent factor (return to the same dates plus a stop after guest details on a held room). The recovery record would name those fields, recommend the existing email or messaging channel, and stop. It would not claim that similar guests convert at a rate you invented. It would not fire an automated send. The revenue manager reads the cites, checks that the hold and the room are still real, decides whether a reminder or a hold-expiry note is appropriate, and sends it.

Contrast, without turning this into a second story: a session that opened the same weekend, viewed rates once, selected nothing, and left. Same hotel, same dates on the calendar. Empty. There is no cart cite and no intent factor beyond a look.

The candidate is a briefing. The send is a human action. Check that the room and rate are still bookable, that the hold has not expired into a promise you cannot keep, and that you are not stacking this note on top of a pre-arrival upsell sequencer path. Upsell sequencing starts after a confirmed reservation. Mixing the two produces a recovery that talks as if the guest already booked.

Draft in the manager's voice, grounded in the cites: the dates they had on the cart, the room type, the step they left. Do not invent availability you have not checked. Do not add extras they never viewed. If the channel is chat rather than email, the same rule holds. The opening line still has to mention the abandoned stay, not a generic offer to help someone book.

Asksuite, HiJiffy, Oracle Hospitality, Mews, and systems like them may be where that send actually happens. Your job is to hand them a candidate with cites, or nothing. Treating a high-intent flag as if the email already went out is a failure mode. The flag is a queue item. Until someone sends, the guest has not been recovered.

Three mistakes show up as soon as the score looks operational. First, a recovery with no cart cite: a polished paragraph that never names dates, room, or last step. Delete it. Second, treating the flag as a sent email: reports that increment recovered when the model fires. Count the sends the manager actually made, and the bookings you can join to those sends, separately from the score. Third, inventing a conversion rate from the existence of the flag. The outcome of this work is the quality of the candidate, not a booked-stay percentage. If leadership wants a measured rate, compute it after the fact on messages that were actually sent, joined to reservations. Do not print a number the model did not observe.

Keep the artifact small enough that a revenue manager can reject it in one pass. Cited session, named intent factor, recommended channel, empty when ordinary. That is the whole working object.