Hospitality CRM: One Guest Profile for Hotel and Restaurant

The guest who stays three nights, eats in your restaurant twice and books one spa treatment is, in all likelihood, three different people to your systems. There is a record in the PMS (property management system), a table number in the restaurant POS, and a phone number in the spa's booking sheet; the only thing linking the three is the guest's own memory. Hospitality CRM, done properly, is the job of pulling those three records into one profile and then putting that profile to work before the guest has walked through the door.

This article walks through the steps a hotel and a restaurant (under one roof, or as contracted neighbors) take to build a unified guest profile, what AI can genuinely do with it, and where data protection law draws the line. It applies from a single boutique property to a multi-outlet resort. We covered the demand side earlier in our hotel demand forecasting guide and the feedback side in our hotel review management guide; this one lives in the stay itself, between those two. The whole sector is mapped in our AI by industry map.

Why now? Take Turkey, where we work with hotels, as a data point: its 2025 tourism year tied growth to per-head spending rather than headcount. About 64 million visitors, $65.2 billion in revenue, $1,008 per visitor, according to ministry figures. The message in those numbers is clear and not limited to one country: revenue growth now depends less on how many guests arrive and more on what each guest spends on the property. Restaurant, spa and ancillaries are where that spending lives; one profile is the tool for not leaving it to chance.

Hospitality CRM vs guest experience management: what is the difference?

A CRM manages conversations and campaigns with the guest; guest experience management collects what happens during the stay (room, meals, spa, complaints, preferences) in one record and feeds it back to operations. The difference is the direction of the data. A CRM sends the guest a message; experience management tells the front desk, the waiter and housekeeping who this guest is.

The industry's technical name for the layer underneath is a CDP (customer data platform): the piece that merges PMS, POS, booking engine, spa software and survey results into one profile. Revinate, Cendyn and Amadeus package this for hospitality; by Revinate's own account, data from Mews (PMS), SevenRooms (restaurant reservations) and Book4Time (spa) flows straight into the profile. Pricing is quote-based, which usually puts it out of reach for a small property. We describe the cheaper route below.

One thing to settle at the start: no CDP cleans your data by itself. Merging profiles depends on a key that identifies the same person across systems (email, phone, passport number, loyalty card). A guest arriving through a tour operator usually lands in your system as the agency's record: no email, no phone. That profile stays empty. In markets where a large share of guests arrive on packages, and Turkey's two biggest source markets are a good example, this is not a footnote.

How do you integrate a hotel PMS with a restaurant POS?

At two separate levels: folio integration and profile integration. Folio integration posts the restaurant check to the room account; plenty of PMS and POS pairs do this out of the box, and it speeds up checkout. Profile integration carries the content of the check (what they ate, what they drank, when they came, whether they liked the table) into the guest record. Most properties have done the first and believe they have done the second.

An example makes the gap visible. At folio level the hotel knows: room 204 spent $110 in the restaurant on Tuesday evening. At profile level it knows: Mr. Weber arrived at 8:30 pm on Tuesday, asked for a sea-view table, ordered sea bass and a bottle of local white, skipped dessert, and the check carries a note saying "service was slow." The first fact is useful to accounting; the second is useful to tomorrow's waiter and next season's sales team.

The technical recipe for profile integration has three parts:

• A shared key: when a table is opened in the POS, the room number or phone number is entered, and the room number resolves to the guest identity in the PMS. Without this one step nothing downstream works.
• Item-level transfer: the POS's API (the data gateway between applications) or its end-of-day export sends check lines item by item rather than as a total. Open-architecture POS systems make this easy; closed ones get by with an export file.
• Preference fields: structured fields in the profile instead of free text: table preference, allergies, preferred drink category, traveling with children. For AI to generate recommendations, the fields have to be consistent.

In the contracted-neighbor scenario (you own the hotel, someone else owns the restaurant) the recipe is the same, with a data-sharing agreement in between; the consent section below explains why.

How does AI actually recommend things to a guest?

Not with a large language model; eighty percent of the job is rules and simple statistics. "Offer a returning guest the wine they chose last time," "if the allergy field is filled, drop that item from menu suggestions," "for a profile with children, surface the early table and the kids' menu": those rules are the knowledge your best waiters have carried in their heads for years, written into a system. AI contributes in two places: finding the patterns you never wrote rules for in POS history, and saying the result to the guest in natural language, in the right language.

The first contribution is the recommendation engine. One season of POS data from a 200-room property shows which items are ordered together, which nationality comes down to dinner at what hour, which tables get requested again. It is e-commerce's "people who bought this also bought" logic applied to a restaurant; the technique is called collaborative filtering, and setting it up is a few days of data work. The second contribution is the messaging layer: profile plus rules plus recommendation becomes a pre-arrival email or a WhatsApp message in the guest's language. Language models are genuinely good at this; you no longer need a staff member who writes three separate texts in Russian, German and English.

Let us build a concrete resort scenario. A 180-room property on the Mediterranean with two restaurants, one of them à la carte, and a spa. The setup: a PMS record is created at check-in, room number is a required field in the POS, and the spa software writes appointments to the profile at end of day. Every morning the system produces three lists: guests dining for the second time (with a note to the waiter about what they ordered last time), guests who spend above average but have never visited the à la carte (a personal invitation for tonight), and guests with a complaint note logged in the last 24 hours (to guest relations). That third list is the most valuable output of the whole arrangement; we will come back to it.

Does personalization really make money for hotels?

It does, but not as much as the numbers in circulation claim. The most-quoted line, "personalization increases revenue by 40%," is a distortion of a 2021 McKinsey study whose actual finding is that fast-growing companies derive a larger share of their revenue from personalization. That does not mean your hotel's revenue will rise 40%. We could not find a primary source for the "10-30% revenue lift" range either; it circulates between vendor blogs.

The more modest figures that can be taken seriously: IHG reported that guests spent an average of $22 extra per night to customize their rooms; a brand's own number, but measured at property level. An Infor survey of hoteliers found 71% of brands want to personalize and only 15% believe they do it effectively; a vendor survey, but its message is familiar: the problem is process and staff adoption more than technology.

Our own arithmetic. The 180-room property above, at 70% occupancy, produces about 3,800 room nights a month. Give the single-profile setup three targets: 15% of guests invited to the à la carte actually go (about $80 in incremental spend each), the right recommendation adds about $10 per meal for returning guests, and ten complaints a month get caught before they reach a review site. The first two lines add up to roughly $13,000-16,000 a month in incremental revenue, which pays for a mid-sized integration project within a season. The third line is hard to price, but the "hidden complaint from the guest who scored you an 8" we described in the review management guide is exactly what that list catches.

How do you spot an unhappy guest early?

The signal is already in the profile; it goes unseen because it is never combined. A main course left half-eaten in the restaurant, a cancelled spa appointment, two calls to the front desk at 11 pm on the first night, a housekeeping note saying "asked for a room change." Each is an ordinary record in its own system; side by side, on the same guest in the same 24 hours, it is an unmistakable warning.

What produces the warning is simple scoring: a weight for every negative signal, a notification to guest relations when the threshold is crossed. AI's role here is classifying free-text notes (the waiter writing "not happy with the table," the front desk logging "AC complaint") as negative or neutral; the rest is addition. The third list in the resort scenario comes from this, and guest relations closes the issue with a gesture or a room change before the guest writes it on Booking.com. In our experience this is the piece properties see returns from fastest; it deserves to be built before the recommendation engine.

Can guest data be used for profiling under data protection law?

Yes, but not on the legal basis hotels already rely on for identity registration. Hotels process identity data under a legal obligation (guest registration rules exist in most countries; in Turkey it is a specific identity-reporting law). Combining restaurant spend, spa visits and preferences for marketing purposes needs a separate lawful basis: explicit consent, or a legitimate interest that has passed a balancing test. The purpose has to appear in your privacy notice. This section is our reading, not legal advice; confirm it with your own counsel under GDPR, KVKK or whichever regime applies.

Three points deserve particular care. Allergy and disability information is health data, a special category under GDPR and KVKK alike, and cannot be written to the profile without explicit consent; yet it is precisely the most valuable field for a good restaurant experience. The fix is a separate, plainly worded consent line at check-in. Second, the contracted restaurant: hotel and neighboring restaurant are separate data controllers, so sharing profiles requires a data-sharing agreement between them and a disclosure in the privacy notice. Third, foreign guests: EU citizens bring GDPR with them, and some large source markets (Russia, for example) have their own data localization rules. The richer the profile, the thicker the compliance file.

There is also a boundary the law does not draw: the creepiness threshold. Reminding a guest of an order from two years ago unprompted, sending a restaurant invitation the minute they leave the spa, putting their child's name in a message; all of it is technically possible and all of it unsettles some guests. Our rule of thumb: keep profile information in staff hands and let it turn into service quality; limit personalization the guest sees directly to information the guest gave you themselves.

Can a small or boutique property do this?

Yes; a 30-room hotel's unified profile starts with a spreadsheet and two integration rules, not a Revinate license. The small property's advantage is low data volume and staff who already know the guests. The system's job there is to make that staff memory written and transferable, so the knowledge does not leave when the seasonal employee does.

The minimum setup: six to eight structured preference fields added to the PMS guest record; room number made mandatory in the POS; a weekly POS export written into profiles; a consent line at check-in. That is a week's work and, in most mid-market PMS products, needs no extra module. The recommendation engine and the automated messaging layer become meaningful once two seasons of data have accumulated; the first season is a collecting season.

Frequently asked questions

Which system should we replace first: PMS or POS?

Neither. The first step is finding out whether your existing systems can export at item level. If they can, the profile layer sits between them; if they cannot, replace that one first, but replacing a system for this reason alone is rarely necessary.

Do we need a loyalty program?

No, but it provides the cleanest key: a card number marks the same person in every system. Without one, the key is room number plus stay dates, which works even for tour-operator guests.

How does AI recommendation affect restaurant sales?

The effect we see is a small, steady lift to the average check: the second bottle, the dessert or the breakfast upgrade offered at the right moment. Do not expect "30% growth"; a working setup adds a few dollars per cover and does it every day.

Is keeping the data in the cloud a compliance problem?

Transfers to servers abroad fall under separate transfer rules in most regimes. Ask where a vendor hosts before you sign; a CDP hosted outside your jurisdiction may need additional safeguards.

So what should you do?

• Choose the key: the one field that points to the same guest in every system (loyalty card, room number plus dates, or phone). Do not discuss integration until this is decided.
• Move from folio to item level: confirm the POS can pass check lines into the profile; a total is not a profile.
• Build the complaint list first: the morning list that scores negative signals from three systems pays back faster than the recommendation engine.
• Add the consent line to check-in; never write allergy or health data without it, never share with a contracted restaurant without an agreement.
• Make the creepiness threshold a written rule: which part of the profile staff see, and which part the guest sees; decide that before the system.

A unified profile has less to do with buying new software than with making three systems recognize the same person. Once they do, the AI recommendation, the early complaint warning and the welcome message in the guest's own language all follow. If you want help working out which key will hold on your property, or whether your current POS gives up item-level data at all, send us your system list and we will do the first assessment together.