Loyalist × Infor

Infor HMS holds the stay and the guest profile behind it, including the preferences a property records over time. Connecting it puts that history on the same record as the guest's restaurant visits, so a returning guest is known by both sides.

How it works

Infor HMS runs the property and keeps a guest profile built to hold preferences and loyalty over repeat stays. That profile is the useful part for a restaurant, because it describes a person rather than a booking. Bringing stays and the guests behind them into Loyalist joins them to the dining room’s own record of the same people, so the guest who returns every spring and always eats in on the first night reads as one relationship instead of a coincidence somebody noticed.

Key benefits

  • Preferences the property has recorded come with the guest. Infor keeps them on the profile rather than on a single stay, which is what makes them worth joining to what the restaurant knows.
  • A stay and a dinner reservation belong to the same person. Somebody staying in the hotel and eating in the restaurant is one record, so neither side depends on whoever happens to remember.
  • Returning guests are legible as returning. Repeat stays and repeat visits read as one pattern, which is the difference between treating a fourth visit as a first and recognising it.
  • Segments can span rooms and restaurant. A list can be the guests who stay regularly but have never eaten in, which is one of the more actionable audiences a property has.

Frequently asked questions

What does a guest profile from Infor add?

Continuity. A profile that carries preferences and loyalty across stays says something about the person rather than about one booking, and that is what makes it useful next to a restaurant’s own history of them.

Does this help a property whose restaurant serves the public?

Yes, and arguably more. Where the dining room serves locals as well as guests, the two audiences are genuinely different, and telling them apart is only possible once stays and bookings sit on one record.

What happens to guests who only ever eat in the restaurant?

They are ordinary guest records, unaffected by the hotel side. The connection matters for the overlap, and the overlap is usually larger than it appears from either system alone.

Last updated

More Integrations

See all integrations

Get started with Loyalist.

If your hospitality group is looking to supercharge your data, we’d love to chat.

Book a Demo