Hotel CRM: what it should hold, how it connects, and when you need one

A hotel CRM is the system that remembers a guest after they check out. The PMS runs the stay: rooms, rates, folios, housekeeping. The CRM keeps one record per person across every stay, enquiry and conversation, holds their consent, and decides what they should hear from you and when. Many properties do not need a separate one yet. Some need one badly and do not know it, because the same guest already exists in their PMS three times.

This guide is for hoteliers, attraction managers and the people who run their systems. It covers what a hotel CRM does that a PMS does not, the data worth keeping, how guest messaging should feed it, what GDPR allows you to do with it, and a test for whether you need one now.

What a hotel CRM does that a PMS does not

A PMS is built around the reservation. Its job is today: who arrives, which room is clean, what goes on the folio. It keeps a guest profile, but it usually creates one per booking, from whatever the booking channel sent. A guest who booked once through an OTA, once direct and once by phone can easily be three people in your PMS.

A CRM is built around the guest. Its job is memory and timing:

• One record per person. It merges duplicates from the PMS, the booking engine, the website and messaging into a single profile.
• History across stays and channels. Not just the dates, but what the guest asked for, what went wrong and how it was fixed.
• Consent and preferences. Which channel the guest wants, in which language, and whether they agreed to receive offers.
• Segments and triggers. Returning guests, families, business travellers, guests who complained last time. Each can get a different pre-arrival message or offer.

If your PMS profile is already clean and the only messages you send are booking-related, the PMS may be enough for now. When to replace the PMS itself is a different question, covered in Signs it's time to switch your hotel PMS.

What guest data a hotel CRM should hold

The test for every field is simple: will someone or something use it to serve this guest better? If not, do not collect it. That is good practice, and it is also the law in Europe. GDPR requires personal data to be "adequate, relevant and limited to what is necessary" for the purpose, and kept no longer than necessary (GDPR, Article 5(1)(c) and (e), read 13 October 2026).

Worth keeping:

1. Contact details and preferred channel. Email, phone, and whether the guest actually answers on WhatsApp, email or SMS.
2. Language. The language the guest writes in, not only the one on the booking. It decides which version of every template they get.
3. Stay or visit history. Dates, room type or ticket type, channel booked through, spend.
4. Stated preferences. Quiet room, early arrival, dietary needs, accessibility needs. Only what the guest told you, not guesses.
5. Service history. A short line per issue: what happened, how it was resolved. The next shift needs it more than the marketing team does.
6. Consent. For each purpose (offers by email, offers by WhatsApp), the date, the source and the wording the guest agreed to.

Leave out what you cannot justify. A field for "estimated income" or a scraped social profile creates risk and no service.

How guest messaging should feed the CRM

Most of what a guest tells you now arrives in messages: what time they land, that it is an anniversary, that the shower was cold. If that stays in the inbox, the CRM never learns it. A guest messaging platform should do three things with the guest record:

• Match. Link each conversation to the right guest, by phone number or booking reference. Decide in advance what happens when the WhatsApp number is not the one in the booking, which is common when a partner booked or the booking came through an OTA.
• Write back. Record requests, preferences and service issues against the guest, not just the transcript. "Late arrival, 23:30" belongs in a field the front desk sees.
• Read. Use the record so replies are personal: the returning guest is welcomed back, and the one who complained last time is not sent a cheerful upsell.

In most hotels this runs through the PMS, which stays the system of record for the booking, with the CRM reading from it. vGuest connects to Mews, Cloudbeds, Guesty and SimpleBooking, among others; without a PMS or CRM connection, an assistant can answer questions about the hotel but not about the guest's own stay. If you are evaluating vendors, the PMS questions to ask before any AI purchase lists what to check, and WhatsApp Business API for hotels covers the messaging side.

Three questions to ask any messaging or CRM vendor:

1. Does data flow both ways, and which fields does it write?
2. How does it merge duplicates, and can staff undo a wrong merge?
3. Where is the data stored, and can you export and delete a single guest's data on request? The full path of a WhatsApp message is in Where does a hotel guest's WhatsApp message actually go?

What GDPR allows you to do with CRM data

A CRM makes marketing easy, which is exactly why the rules matter. For promotional messages, most hotels rely on consent, and the burden of proof is on you.

• Consent can be withdrawn at any time, and it must be as easy to withdraw as to give (GDPR, Article 7(3), read 13 October 2026).
• Guests can object to direct marketing at any time, after which their data can no longer be used for it (GDPR, Article 21(2) and (3), read 13 October 2026).
• Guests have a right of access and a right to erasure (GDPR, Articles 15 and 17, read 13 October 2026). Your CRM must be able to find everything about one person and remove it.

So store consent as data, not as a note: a field per purpose, with a date and a source. When and how to ask for it, especially on WhatsApp, is covered in WhatsApp marketing consent: when to ask hotel guests. Booking confirmations and pre-arrival information are service messages, not marketing, and should never be held hostage to a marketing opt-in.

This is general information, not legal advice. Rules differ outside the EU and UK, so check with whoever owns data protection for your property.

Hotels and attractions: the same idea, a different source system

For a water park, a museum, a tour operator or an activity venue, the ticketing or booking system plays the role of the PMS. The differences that shape the CRM:

• Visits are shorter and often by groups. The record that matters may be the family or the school, not one person.
• Repeat visits are seasonal. The return-visit message is timed to the season or the school holidays, not to a checkout date.
• Questions come before the visit. Opening hours, weather, what to bring, whether the slide is open. These conversations are the richest source of preferences you have.

Attractions also share a lot with hotels: the same guest might stay at the hotel and visit the attraction next door, and both want to recognise them. How AI assistants differ between the two is covered in AI for attractions is not AI for hotels.

Do you need a separate hotel CRM yet? A five-question test

Answer yes or no:

1. Do returning guests make up a meaningful share of your bookings, and do you want more of them?
2. Do you run more than one property or venue, and want one view of the guest across them?
3. Does the same guest appear as several profiles in your PMS?
4. Do you want to send segmented messages (families, business travellers, past complainers) rather than one message to everyone?
5. Is direct booking a priority, with email or WhatsApp campaigns you actually plan to run?

Mostly no: stay with a clean PMS profile and a messaging platform that writes back to it. That is the right stack for many small properties, as argued in Hotel tech stack for small hotels. Mostly yes: a CRM will pay for itself in recognition and timing, as long as the data going in is clean. Loyalty built on that recognition, rather than on points, is the subject of Rethinking loyalty: from points to personalization.

Checklist: before you buy a hotel CRM

1. Name the jobs. Write down three messages or decisions the CRM should drive. If you cannot, you are not ready.
2. Clean the PMS first. Merge duplicates and fix missing emails and phone numbers. A CRM fed bad data multiplies it.
3. Map the connections. PMS, booking engine, messaging, payment, and for attractions, ticketing. Which way does each one flow?
4. Design the consent fields. One per purpose and channel, with date and source.
5. Agree on retention. How long you keep a guest who never returns, and who deletes it.
6. Decide who owns it. A CRM without an owner becomes a second, worse PMS within a year.

Takeaway

A hotel CRM is not a bigger PMS. It is the memory of the guest relationship: one record per person, the consent to contact them, and the history that makes the next message relevant. Many small properties can get most of that from a clean PMS and a messaging platform that writes back to it. When guests return, properties multiply or direct booking matters, a CRM earns its place, provided the data that feeds it, much of it now arriving by message, is clean and collected lawfully.