This template belongs to the service recovery approvals hub, which covers what to inventory before a guest messaging migration. Use the records map to gather system answers and the who-can-license answer to settle field 8; this page is where those answers get written down for the decision-maker.
Copy this blank brief
Fill every field from what the guest operations director tells you. Write "unknown" rather than guessing, and "estimate" beside any number nobody has counted.
Re: Service recovery history at [hotel group]: referral brief
1. Company: [full-time staff at peak], [number of properties], [countries], [years operating] 2. Task: [how complaints are resolved when more than one team offers a remedy, in the director's own words] 3. Systems: [property management system], [guest messaging platform, and whether it is being replaced], [point of sale], [shift log or ticket tool] 4. Years of history: [threads from year to year], [service requests from year to year], [charge adjustments from year to year] 5. Volumes (estimates): [complaints logged per year], [bill credits with a recovery reason per year] 6. Record owner: [operating company or management company] and [role that runs each system] 7. Open question: [the one thing nobody can answer yet, such as what the outgoing messaging tool exports] 8. Authorized contact: [the CEO, who can authorize licensing], [co-signer such as counsel], sponsor [role]
Not attached: no threads, folios, screenshots, guest names or exports.
Eight fields is deliberate. A director can answer them from memory and a project plan in one short call, and the executive who reads the brief can decide in two minutes whether to take a meeting.
Field notes: what a usable answer looks like
The table shows a good entry for each field and the things that tempt people but must stay out.
| Field | A usable answer | Keep out |
|---|---|---|
| 1. Company | "About 340 full-time staff at peak, four properties, U.S., since 2009" | Revenue, occupancy, owner names |
| 2. Task | One plain sentence about conflicting remedies and who decides | Policy manuals, training decks |
| 3. Systems | Product names as text, with "being replaced" where true | Admin URLs, account numbers, credentials |
| 4. Years | A range per record class, and where coverage changes | Claims nobody has checked |
| 5. Volumes | Rounded figures from an existing report, marked as estimates | Counts run specially by opening records |
| 6. Record owner | The legal entity, then the operating role | Opinions about who "really" owns data |
| 7. Open question | One neutral question | Anything that reads as a promise of value |
| 8. Authorized contact | The CEO, plus counsel where guest data is involved | A front office manager or system admin as approver |
Two fields need more care in hotels than in most sectors.
Field 4, years of history. The property side often holds more structure than people expect. In Oracle OPERA Cloud, service requests are tied to a profile, reservation or room and record who closed each one and the action taken, and a Service Recovery reason code type exists only once the Service Requests control is switched on. So ask when that control went live: that year is often where traceable recovery history begins.
OracleField 6, record owner. Many hotels run under management or franchise agreements, and systems may be shared with a brand. Name the entity that holds the records, not the flag on the building. If ownership is unclear, write "to confirm" and let counsel settle it before the introduction.
A completed example (Illustrative)
Illustrative and fictional: the group, systems and figures are invented to show a finished brief. It is not a real company, a forecast or a deal.
Re: Service recovery history at a city hotel group: referral brief (Illustrative)
1. Company: about 340 full-time staff at peak, four full-service hotels, United States, operating since 2009 2. Task: resolving guest complaints where the front desk, sales and engineering offered different remedies for the same stay, and deciding which one the group honors 3. Systems: property management system with service requests switched on; a guest messaging platform being replaced next spring; point of sale in each outlet; a shared shift log 4. Years of history: messaging threads since 2020; service requests since 2018; charge adjustments with recovery reason codes since 2018 (estimate, not verified) 5. Volumes (estimates): about 2,400 complaints logged a year across the four hotels; about 900 bill credits a year with a recovery reason code 6. Record owner: the operating company, which holds the property and messaging contracts; guest operations director runs messaging, finance runs billing 7. Open question: whether the outgoing messaging tool can export threads with staff names and timestamps, or only guest contact details 8. Authorized contact: group CEO, with general counsel for guest privacy; guest operations director as sponsor
Not attached: no threads, folios, screenshots, guest names or exports.
Reading it as the executive would: the property side is structured and runs back to 2018, the messaging side is younger and has a real end date, and the open question sits exactly where the promise history could be lost. That is a fair description a CEO can act on. It also shows the pattern the exception examples page walks through, two teams offering two remedies, without describing any actual guest.
Lines that never go into a service recovery brief
Guest messaging threads carry names, room numbers and whatever the guest wrote. Under the EU General Data Protection Regulation, Article 4(1) treats any information relating to an identified or identifiable person as personal data, and many other privacy laws take a similar view. That is why the brief describes record classes and never their contents.
- No message text, even paraphrased, and no screenshots of the messaging tool.
- No bill numbers, room numbers, dates of stay or loyalty IDs.
- No staff names; roles only.
- No exports "just to show the format", and no requests for logins.
- No statement that the records are valuable, wanted or likely to be licensed.
Partners never ask for or handle raw client records. Discovery stays at metadata level: what exists, how much, how long, which system and who owns it.
Checks before the brief is forwarded
Run through these with the sponsor before the brief goes to the executive.
- The guest operations director has read every field and agrees each value is theirs.
- The group appears to meet the baseline: 50+ full-time employees at peak (contractors excluded), documented operating history, rights to license 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.
- The "Not attached" line is intact.
- You have signed the Channel Partner Agreement. Credit goes to the first valid introduction within the 90-day window, credited when the company submits a verified application.
- Nothing implies an outcome. Buyer interest, the rights review result, de-identification needs and any offer stay unknown until SourceX reviews the records with the company.
For the covering email, start from the introduction email templates for CX consultants; the CX consultant referral program explains how introductions fit a consulting practice, and the client opportunity brief generator drafts similar briefs for other workflows. 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.
When all eight fields are filled and the CEO has agreed to a conversation, register as a partner, check the group against who qualifies, read the program terms, and send the brief with your introduction.