Loyalty context retrieval

Confirmation is the last clean chance to put prior-stay context on the reservation without guessing. Load the guest record from the property CRM or PMS first. Then retrieve. Then show a draft. Then stop.

Oracle Hospitality, Mews, Revinate, and Cloudbeds are the class of systems that already store stays, comments, and complaint tickets. Retrieval should query those records, not a parallel guest file. Match on the identifiers your front office already trusts: loyalty number, profile ID, email, or a prior confirmation number the guest used.

What you load is bounded. Stay comments, preference flags, and closed complaint notes for this guest. You do not load every review on the brand, every house-use comment, or another guest with a similar name. If the match is weak, do not retrieve. A near-match is how one couple's latex allergy lands on another couple's confirmation.

Load stays and complaints as separate sources that happen to live on the same profile. A stay comment is a preference candidate. A complaint is a preference candidate only for the specific miss it records, and only with its ticket cite. Do not merge them into a single guest personality paragraph.

This pass is not preference extraction from booking notes. Notes on this booking belong to this stay. Loyalty context is only what previous stays and complaints already recorded.

A retrieved preference is ready for the agent when it includes the CRM stay or complaint it came from. The cite is the stay dates or confirmation number, or the complaint ID, plus the snippet that supports the claim. No cite, no preference.

Work the retrieval in that order. Query the loaded record for preference-like language and complaint outcomes. Keep only hits that resolve to a stay or ticket. Attach the cite to the line the agent will see. Rank nothing for marketing value. Rank for whether a colleague could open the same record and find the same sentence.

Show the agent the preference in the property's field names (bed, floor, amenities, accessibility), the cite underneath, and the snippet available to expand. Do not bury the cite inside a paragraph of generated prose. If the model cannot point at a stay or ticket, it returns nothing for that field.

One illustration. A returning guest books two nights. The CRM shows a stay last April. The stay comment reads "requested a room away from the elevator; assigned 412." A closed complaint from that stay notes that housekeeping missed a rollaway the guest had confirmed by phone. Retrieval should surface two draft lines: quiet-room request, cite April stay and room 412 comment; rollaway missed after phone confirm, cite that complaint ID. It should not add a pillow type, a floor number the comment never named, or a VIP-feel summary. The agent reads those two lines against the open reservation, asks the guest if they still want a quiet room and a rollaway, and only then updates the profile fields the property actually uses.

If retrieval returns "prefers extra pillows" and the only nearby text is a review-style sentence with no stay attached, drop it. A preference with no stay cite is the first failure mode. It looks helpful in a sidebar and it is fiction.

If the profile and stay history say nothing about a preference, the field stays empty. Empty is the correct output. Do not fill it from brand defaults, from what guests like this usually want, or from a model completion that sounds plausible.

Inventing a pillow type is the failure mode that makes this obvious. Nobody logged a pillow. The model has seen pillow requests in other records. It writes feather-free pillows onto the confirmation draft. Housekeeping sets the room. The guest did not ask. You now have an invented preference sitting where a blank should be.

The same rule covers allergies, accessibility, bed type, and arrival time. Silence is not a soft no. It is unknown. Unknown stays blank until the guest or a prior stay says otherwise.

Complaints follow the same empty rule in reverse. If a complaint was logged and resolved, retrieve the complaint and the resolution, with the cite. Do not turn a single late-checkout refusal into a standing always-late-checkout flag unless the profile already has that flag or the guest restates it at confirm. A complaint is evidence of what went wrong once. It is not a standing order unless someone stored it as one.

Retrieval auto-populates a draft guest profile at confirmation. It does not auto-write the live profile. A reservations agent still confirms every line before it becomes house instruction.

Treat the snippet as source material, not as the profile. That is the second failure mode. The CRM comment says away from the elevator. The draft profile field becomes must have a courtyard king, high floor, no elevator. The extra clauses were not in the cite. If you write that string into the PMS, guest preference-based room setup will execute a room the guest never requested.

The agent's job is narrow. Open the draft. Open the cite. Check that the preference is still relevant to this stay (dates, occupancy, room type). Ask the guest when the cite is old or the request is operational (rollaway, connecting rooms, accessibility). Accept, edit, or discard. Only accepted lines write to the profile or to the reservation comments that operations will read.

Do not let the model write the profile on a timer, on high confidence, or because the guest clicked confirm on a rate. Confirmation of the rate is not confirmation of the preference set.

If the agent is unavailable, hold the draft. A delayed blank profile is safer than an unattended write.

Once the agent has confirmed, downstream steps may use the stored preference. They should not reuse the raw retrieval snippet.

Room assignment and setup should read the confirmed profile fields, not the retrieval hit. Welcome copy should not quote a complaint. A personalized welcome message generator can mention a confirmed request (we have noted a rollaway) and must not retell the missed-rollaway ticket. Re-engagement later should use confirmed, still-valid preferences only. A hyper-personalized re-engagement generator that lifts an old complaint into an email is retrieval leaking into marketing.

Keep a short audit trail for the agent: which stay or complaint was cited, what the agent accepted, what they left blank. That trail is how you catch the three failure modes in review: a preference with no stay cite, a snippet treated as the profile, and an invented detail (pillow type, floor, bed) the CRM never recorded.

If a later stay arrives and the CRM is still silent on a field, retrieve again and leave it blank again. Loyalty context is not a one-time backfill. It is a cited lookup at each confirmation.