Guide · Systems

How to manage hotels, restaurants and other physical locations in a CRM

CRMs were built around companies and people. Hospitality runs on places: sites, outlets inside hotels, groups and chains, venues that rebrand or close. Here is how to set a CRM up so it keeps them straight.

By Nic Hovey, founder of Mythaeon · Published 18 October 2026

Why physical locations are uniquely hard in a CRM

Most CRMs assume a company has one name, one website and one set of contacts. Hospitality breaks every one of those assumptions.

• Names aren't unique. There are dozens of restaurants called "The Olive" or "Casa Mar", and one business can be written five different ways.
• One building, many businesses. A hotel can hold two restaurants, a rooftop bar, a café, banqueting and room service, sometimes with different managers and budgets.
• One business, many sites. Groups, chains and franchises share a brand name and often a single website.
• Addresses are messy. Street numbers, suite numbers, resort addresses, abbreviations and different formats for the same place.
• Contact details are shared or generic. An info@ inbox for the whole group, a front-desk phone number, or a venue that only has an Instagram account.
• Places change. Venues rebrand, change owners, close, reopen and open only for the season.
• People move. Turnover is high, and the general manager or head chef you knew may now run a different site.
• Sources disagree. Map listings, booking platforms, directories and your own team's notes each spell and describe the same place differently.

Each of these on its own creates duplicates. Together they make a hospitality database drift out of shape fast unless it is designed for places from the start.

Step 1: One record per physical location

The basic unit should be the place you could walk into: one company record per operating site. A group with six restaurants is six location records, not one. This keeps each site's address, contacts, orders and history separate, which is what your team actually needs when they pick up the phone.

Store the location details in consistent fields: standardised address, city, country, phone, website, a status field, and a location identifier (see Step 3).

Step 2: Groups, chains and hotel outlets

• Groups and chains: create one parent record for the group and link each site to it. Most CRMs support this; in HubSpot it's a parent and child company association. You can then report on the whole group while keeping each site's detail.
• Hotels with several outlets: if each restaurant or bar has its own decision maker or its own ordering, give it its own record linked to the hotel as the parent. If one person runs purchasing for the whole property, one hotel record with the outlets noted is usually enough.
• Food halls, markets and airport concessions: treat each stall or unit as its own location, linked to the site that houses it.

Decide the rules once, write them down, and apply them every time. Inconsistent structure is itself a source of duplicates.

Step 3: Identifiers you can trust

Names are the least reliable way to tell places apart. Use identifiers that stay the same however the name is written:

• Map listing ID. Map services such as Google Maps give each listed place its own ID. It is one of the most reliable ways to say "this exact place", and it survives spelling differences. Refresh stored IDs now and then, because they can change when a business moves or closes.
• Standardised address, ideally with map coordinates. Two records at the same address are worth a look, but remember that a hotel address can hold several businesses.
• Website domain. Useful, with a caution: a group often shares one domain across all its sites, so a matching domain may mean "same group", not "same location".
• Phone number, stored in one format. Helpful, but watch for shared central lines.
• Name. A hint only. Use it to flag possible matches for a person to review, never to merge on its own.

The practical rule: rely on the identifiers that point to one specific place, use the ones that can be shared as supporting evidence, and send anything uncertain to a human to check.

Step 4: People move, places stay

• Link contacts to the location they work at, not just to the group.
• Record their role (general manager, head chef, bar manager, purchasing) so you know who to reach even when the person changes.
• When someone moves to another venue, update their link and keep their history, rather than creating a new contact.
• Prefer personal work emails over shared inboxes for matching people, and keep shared inboxes on the location record.

Step 5: Closures, rebrands and seasonal venues

• Never delete a venue that closes. Mark it closed with a date. If you delete it, it will come back in the next list you import, looking brand new.
• Rebrands: mark the old name as rebranded and link it to the record for the new name, so history carries over.
• Seasonal venues: use a status for seasonal or temporarily closed, with the expected reopening, so nobody contacts them mid-closure.
• Re-check regularly. Compare your locations against current map listings every few months to catch closures and changes early.

Step 6: Check every new list against what you know

New locations usually arrive in bulk: an event list, a directory, a booking platform export or a list your team pulled together. Before any of it goes in:

1. Standardise names, addresses and phone numbers.
2. Match each row on location identifiers first, then flag name-only matches for review.
3. Check against closed and rebranded venues as well as active ones.
4. Add only what is genuinely new, and update existing records with anything better.

About the author. Nic Hovey is the founder of Mythaeon. He started in restaurant kitchens and has spent years building CRM setups, sales programs and automated workflows, much of it on keeping hospitality locations straight. He now sets up and runs systems that take the routine admin off food and drink teams. LinkedIn