This map is part of the service recovery approvals guide, which covers what to inventory before a guest messaging migration. The hard case on two conflicting remedies walks through the decisions; this page shows which system holds each record and which string connects it to the next.
Where each piece of a service recovery decision is stored
| System | Record it holds | Linking key | Usual owner |
|---|---|---|---|
| Guest messaging platform | Guest's complaint, staff replies, written offers | Phone or contact, sometimes reservation number; timestamps; agent name | Guest operations director |
| Property system: service requests | Complaint or incident against a profile, reservation or room; resolution and follow-up | Reservation number, room, closed-by user | Front office manager |
| Property system: engineering task | Fault, technician, time fixed | Room number, service request reference | Chief engineer |
| Restaurant point of sale | Check with comp and the manager who approved it | Room charge or table, check time, manager ID | Food and beverage director |
| Manager shift log | Verbal offers, escalations | Date, room, staff name (free text) | Duty managers |
| Property system: folio | Adjustment with department, reason code and text | Reservation number, posting time, user | Finance and front office |
Oracle's OPERA Cloud documentation shows how much the property side can carry when it is configured for it: service requests linked to a profile, reservation or room that record who closed them and the action taken, and recovery adjustments that tie a department, a reason code and clarifying text to the posting. The Service Recovery reason code type only appears when the Service Requests control is active, so whether that link exists at a given property is a configuration fact to ask about, not assume.
OracleThree keys: reservation, timestamp, staff member
Reservation or room number. The spine of the case. Property records carry it natively. Messaging threads carry it only if the platform matches the guest to the stay; otherwise room number plus date becomes the substitute.
Timestamp. Orders the promises. It is what shows that the night agent's written offer came before the restaurant manager's spoken one, and that the director's decision came after both.
Staff member. Ties each promise to a level of authority. A promise inside an agent's approval limit carries different weight from one outside it, and the folio posting user shows who finally applied the remedy.
A useful test for the guest operations director: pick any folio credit with a recovery reason code and ask whether the staff could, in principle, find the message that started it. The answer, by year, is the coverage statement.
One case joined end to end (Illustrative)
Invented for this page. A 1,100-person hotel group runs a 280-room city hotel. A guest books three nights at $290.00 a night in room 714. The group's fictional policy lets front office agents offer up to $100.00 without a manager.
| Hop | Record | Key carried | Joins to |
|---|---|---|---|
| 1 | Messaging thread, night one 23:10: "air conditioning has failed" | Guest contact; time; room 714 typed by the guest | The stay, by room and date |
| 2 | Agent reply 23:14: "We will take care of tonight's rate" | Agent name; time | The promise, outside the agent's $100.00 limit |
| 3 | Service request 23:40 under an engineering code | Reservation number; room 714 | Technician task closed 00:30 |
| 4 | Restaurant check, day two 07:45, breakfast comped | Room charge to 714; manager ID | Manager's spoken offer of 20% off the stay ($174.00) |
| 5 | Checkout: no credit on folio; guest cites both offers | Reservation number | Escalation to the guest operations director |
| 6 | Folio adjustment: $290.00 for night one, recovery reason code, text naming the written promise | Reservation number; posting user | Service request closed with action taken |
The director honored the written promise, kept the breakfast comp and withdrew the 20% offer with an apology. Every hop carries at least one key shared with the next, so a reviewer can walk from the $290.00 credit back to the 23:14 message. That walk is the evidence.
When a key is missing, what the case loses
| Missing key | Typical cause | What the reviewer loses | Substitute to ask about |
|---|---|---|---|
| Reservation on the thread | Messaging keyed to phone only | Which stay the promise belongs to | Room number in the text plus dates |
| Service request | Messaged complaints never logged | Proof the property recorded the issue | Engineering task or shift log |
| Staff name on the offer | Shared inbox login | Whether the offer was within authority | Shift roster for that time |
| Recovery reason code | Credit posted as a generic adjustment | Why money moved | Adjustment text; director's email |
| Spoken offer | Never written down | The conflict that forced the decision | The decision text, if it mentions the offer |
A property missing one key in this table still holds a usable history; it should state which years are fully joined and which depend on substitutes. The workflow map template gives the company a blank version of this map, and the warranty claims data page shows a similar promise-to-remedy chain outside hospitality. For ticket-based support desks, see the Jira Service Management export page.
JiraCoverage and authority before an introduction
Ask the guest operations director, without requesting any thread or folio: which systems store the reservation number, since when service requests have been used, whether staff log in individually to the messaging tool, and roughly how many folio credits with recovery codes are posted a year. Then find out who can authorize a licensing discussion; the authority tree for these records covers owner-operated, managed and franchised structures.
Guest threads are personal data, so rights review and de-identification decide what could ever be included. The company needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license the records and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. Partners sign the Channel Partner Agreement before submitting; the first valid introduction within the 90-day window is credited when the company submits a verified application. The referral brief template turns these answers into an introduction, and more hotel workflows are on the hospitality page.
Next step
Refer a company. Earn up to $100,000. Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.
If a hotel client can walk a folio credit back to the message that promised it, register as a partner, check the company against who qualifies, and read the program terms before you introduce the decision-maker.