Incomplete reservation flagging

A confirmed reservation can still be operationally incomplete. The guest has a rate, dates, and a room type. The PMS record may still lack a billing address, a loyalty number the guest quoted on the call, a second-guest name, or an arrival window the property needs for keys and parking. Quality work here is not rewriting the booking. It is naming the missing field so a reservations ops lead can complete the record before arrival.

The classifier's job is narrow. Load the booking as it stands after confirmation. Compare required fields against what is actually present. If something is missing, or two stored values cannot both be true, raise a flag that cites the field. If every required field is present and consistent, leave the flag empty. Empty means complete. It does not mean look later.

Ops still owns completion. The flag is a work ticket, not a cancellation, not a new guest fact, and not a reason to invent a document the guest never sent. Channel confirmations, voice bookings, and pre-registered arrivals all hit the same rule: confirmation is commercial, completeness is operational.

A useful flag is a citation, not a mood. Incomplete with no field forces someone to reopen the whole folio. Missing estimated arrival window, required by house policy, not written to the reservation, tells the desk what to collect. Conflicting billed guest name versus cardholder name on the same profile tells them what to reconcile. Do not invent a conflict that is not in the record.

Cite the source of the requirement when you can: property policy, rate-code rule, or a channel field that never mapped into the PMS. Cite the current value when a field exists but collides with another. Do not cite a passport, visa, or government ID unless that identifier is required for this stay and is actually absent. A leisure domestic stay that never asked for a passport should not grow a missing-passport flag.

When the booking is complete, the output stays empty. That silence is the quality signal. Alerting on every confirmation trains the team to ignore the queue. A complete record produces no task and no please-review noise.

Property-management and guest-messaging platforms sit in the same class here. Oracle Hospitality, Mews, Cloudbeds, and Canary all hold confirmed reservations and guest profiles. The check reads whatever those systems already store. It does not replace their confirmation flow.

Load the reservation in the system of record after the confirmation event, not from a chat transcript and not from a half-synced channel snapshot. You need the fields the house will operate against: names, dates, rate code, room type, payment method, contact, and any property-required extras such as estimated arrival, vehicle plate, extra adult, or loyalty ID.

Walk each required field in order. Present and consistent: skip. Absent: flag with the field name and where you looked. Present in two places with values that cannot both be true: flag the conflict and quote both values. Do not merge them. Do not pick a winner. A guessed correct name is still an invented fact.

Then stop. Ops fills the gap with the same tools they already use: a call, a reply to the confirmation, a cited line from preference extraction from booking notes if a free-text comment already contains the missing arrival time, or a document path such as id document OCR parser when the stay actually requires an ID image. The classifier does not write the field.

Two adults, one empty arrival window

A Thursday confirmation for two adults, king room, prepaid BAR. Email and mobile are present. Loyalty number and billing address are present. The property requires an estimated arrival window for key-packet prep. The reservation's arrival-time field is blank. The confirmation email asked for it. The guest never answered.

The flag is missing estimated arrival window, source house arrival policy, current PMS value empty. Nothing else fires. Do not add a missing passport. Do not mark the booking cancelled. Do not write 15:00 as a default arrival.

Ops sends a short request, writes the window when the guest replies, and the next run returns empty. If the same booking had every required field filled, including that window, the flag would be empty on the first pass. No alert. No quality-review queue item.

A flag with no field is not a quality flag. It is a search assignment. The team will ignore it or spend a long stretch hunting through notes, traces, and the guest's email. If the model cannot name the field, it should not fire. Route unnamed output to a model-quality review, not to the reservations worklist.

Treating the flag as cancelled is worse. Incomplete is not void. The guest still has a confirmed stay. Routing the record into a cancellation queue, releasing the room, or sending a message that the stay could not be confirmed creates a real inventory problem or a real complaint. Keep the flag on a completeness worklist. Leave inventory and confirmation status untouched until a human decides otherwise.

Inventing a missing passport, or any document the stay did not require, creates false work. If someone then asks the guest for it, you have a privacy and trust problem. The same rule applies to inventing a loyalty number, a company IATA, or a second-guest nationality. If loyalty context retrieval does not return a match, that is not automatically a missing-field flag unless the rate code requires a validated member ID and the ID field is blank.

Channel sync lag is a related trap. A field can look missing because the central reservation system has not written it yet. Load after confirmation has settled in the PMS, or you will flag complete bookings in a batch every afternoon and train the team to dismiss the queue.

The check is a read of the confirmed record, then a write of a structured exception. It does not own the guest conversation. A conversational booking agent may have collected extras during booking. Those extras only count once they land on the reservation. Preferences in notes are hints for ops, not automatic field writes, unless your process already maps a cited note into a named field.

Keep the alert in the ops queue the team already works: PMS task, inbox, or messenger. The payload should be reservation ID, cited field, current value or empty, conflicting value if any, and the policy or mapping that made the field required. That is enough to complete the record without hunting across the folio.

Do not auto-cancel, auto-modify the rate, or auto-fill from a model guess. Auto-fill is how a wrong ID number or a guessed arrival time becomes source of truth in Oracle Hospitality, Mews, Cloudbeds, or Canary alike. The vendor does not matter. Completeness still belongs to ops.

The quality outcome is a cited gap or a clean empty. Ops completes what the guest still owes. Re-run the check after the edit. Empty after the edit means the confirmation is now operable. A new flag must cite a different remaining field, not repeat the one already filled.

If ops cannot obtain the field because the guest is unresponsive or the corporate booker is offline, document the attempt on the reservation and leave the flag visible until policy says the stay can proceed without that field. That is still a named gap. It is not a cancelled booking and not a fabricated value.

Train the queue on three rejects: unnamed flags, cancellation treatment, and invented documents. Those three errors cost more than a missed arrival window. The working loop is load, cite or stay silent, let ops fill, re-check. Stop when empty.