AI Adoption GuideHospitalityReturn
Hyper-personalized re-engagement generator
LLM drafts return offers referencing specific past stay details, preferred dates, and individual preferences.
Hospitality processBookConfirmPrepareArriveStayDepartReviewReturn
By Don, DoneThat’s AI coach · updated
A usable draft cites a confirmed stay or preference
A return-offer draft is usable when it cites a confirmed past stay or a confirmed individual preference. If those fields are silent, those parts of the draft stay empty. Marketing still sends. The model does not auto-send, and it does not quote a complaint.
Hyper-personalized here means checkable, not decorative. "We would love to welcome you back to the courtyard room you occupied in October" is a cite if October and courtyard are on the reservation. "We remember how much you enjoyed your stay" is not a cite. It names no stay, no date, no preference. Reject that line or send it only as generic campaign copy, not as a personalized re-engagement.
Guest-relations and marketing leads should treat the generator as a writing aid sitting on top of the guest record, not as a memory of the hotel. The record is the source. The draft is a proposal. The send is a human decision.
When the guest is in a loyalty program, load program facts through loyalty context retrieval so tier and qualifying stays come from the same confirmed profile you will cite.
Pull stay facts and preferences before you generate
Load confirmed stay details and preferences first. Then draft. Reversing that order is how invented room types and invented seasons get into the inbox.
Stay fields worth loading, when they exist: property, room product or view as booked, arrival and departure dates, party composition if stored, and any return window the guest already stated. Preference fields worth loading, when they exist: bed type, floor, pillow, accessibility needs the guest asked you to remember, dietary notes captured at booking or in-stay, and language. Preferred dates belong in the draft only if the guest or the profile named them. A marketing calendar is not a preference.
Property management and guest CRM systems already store most of this. Revinate, Oracle Hospitality, and Mews sit in that class: profile, stay history, and campaign lists. Use them as the record you read from. Do not claim a specific workflow, integration, or feature for any of them. If your stack is different, the rule does not change: confirmed fields in, silent fields omitted.
Ask front office or CRM operations for a guest extract that includes last stay and preference flags, not a free-text comment dump. Free-text often contains complaints. If comments are in the extract, strip complaint-like lines before they reach the prompt.
Do not dump the entire folio into the prompt. Pass only fields you are allowed to mention in a marketing email. Rate codes, negotiated company names, and payment comments often should stay out. Complaint text always stays out.
If you rank who to contact, keep that separate. A return propensity scorer can order the queue. This generator writes copy only for guests already chosen, and only from fields that are present.
Illustrative example: a marketing lead prepares a spring invitation for a guest whose last stay was two nights in a courtyard king in October, with a profile note "late checkout when possible" and a blank dining field. The draft may mention the October courtyard stay and late checkout. It must not invent a spa credit, a sea view, or a favorite restaurant. Preferred dates are blank, so the date line stays blank or uses a non-claiming phrase such as "on your next trip," not "for your usual March visit."
Write cites into the draft, and leave silent fields blank
Every personal claim in the draft should point at a loaded field. Put the cite in the sentence, not in a footnote only staff can see. The person who sends should be able to glance at the profile and confirm the line.
A practical sequence:
- State that you are inviting a return, without claiming a ritual ("as you do every year") unless the record shows a pattern of stays you are allowed to summarize.
- Add one stay cite if a stay exists.
- Add one preference cite if a preference exists.
- State the offer marketing has approved (package, rate fence, or date window).
- Close. Do not add extra personalization to fill space.
When a field is silent, leave it blank. Do not substitute "your recent visit" for a missing stay date. Do not substitute "your usual room" for a missing room product. Empty is the correct output for a silent field. Filling the hole to sound warm fails the quality outcome even if someone later hits send.
Housekeeping and arrival-setup notes are operational. They are not automatically email copy. If a preference exists so the room can be set correctly on a future stay, keep that path in guest preference-based room setup. Do not paste pillow or minibar notes into a re-engagement letter unless marketing has a reason and the guest would recognize the detail as welcome, not surveillance.
Do not quote a complaint. Do not paraphrase one ("sorry again about the noise"). Complaint language in a return offer turns a private service issue into campaign copy. Keep those tokens out of the prompt. If recovery is unfinished, handle it as a guest-relations case, not as input for the generator.
Checkout copy is a different job. A personalized farewell message generator closes the stay that just ended. This generator opens a later invitation. Do not recycle farewell lines as if they were a new offer.
A person still sends; the model never does
The artifact is a draft. Marketing or guest relations edits the offer, checks the cites, and sends from the approved channel. Do not auto-send. Generating is not delivering. A queue of drafts is not a campaign that has gone out.
Before send, check:
- Each stay or preference claim matches the record you loaded.
- No complaint appears, quoted or hinted.
- Silent fields are still blank.
- The offer is one you are actually running.
- The from-name and channel match how this guest usually hears from you.
Treating the draft as sent is a failure mode. Copy that "sounds personal" still needs a human who can see that the courtyard cite is wrong, or that the model pulled a service ticket. The quality outcome is a draft a sender can stand behind. Delivery stays a separate act.
When to refuse the draft and send something else
A draft with no stay cite and no preference cite is not hyper-personalized. Strip the false intimacy or send a standard return campaign instead. Do not label it personalized.
If your process has no human send step, you do not have this use case. You have unattended mail.
Quoting a complaint, or alluding to "the issue during your stay," fails even when the rest of the cites are correct. Drop those tokens and, if needed, write a separate recovery note outside this generator.
Other refusals: a stay at a sister property the guest never booked; a preference attached to a shared email that belongs to someone else; preferred dates taken from a seasonal calendar rather than the profile. Each fails the same test. The draft cites a confirmed field, or that part stays empty.
When the record is thin, send a non-personalized return offer, or wait until a later stay adds facts you can cite. Empty stays empty. Marketing still sends. The generator's job is to withhold false detail, not to maximize warmth.
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