Hotel Mapping: Fixing Duplicate Hotels in Multi-Source Inventory

Your sales team searches for a hotel in Belek and gets three results: "Beach Resort Hotel", "Beach Resort Hotel & Spa" and "BEACH RESORT HTL". Each one has a different price, a different room list and a different photo. It is the same hotel. The customer does not know which one to pick, and often your own team does not either. This is the duplicate hotel problem, and it shows up at almost every tour operator that buys hotel inventory from more than one source. The fix is called hotel mapping.

Why do duplicate hotels appear?

A tour operator rarely works with a single supplier. Hotels come from incoming agencies on SAMO or Sejour, from bed banks, from direct contracts and sometimes from the hotel's own channel manager. Every one of these sources has its own hotel ID, and there is no shared key between them.

On top of that, the same hotel is described differently in every system. The name may be shortened, written in capitals or extended with "Hotel", "Resort" or "& Spa". The address may point to Belek in one source, Serik in another and simply Antalya in a third. Coordinates can be off by a few hundred meters. Hotels also change names, owners and brands over time, and not every supplier updates its data on the same day.

When all of this content is loaded into one system without a matching step, each source creates its own hotel record. One physical hotel becomes three products.

The cost is more than cosmetic

Duplicate hotels look messy, but the real damage is commercial.

Search results get crowded and harder to read, which lowers conversion. Price comparison stops working: the cheapest source for a hotel sits in a separate record, so your system cannot show the best offer or pick the best supplier automatically. Stop-sales and allotment updates can be applied to the wrong record, which is a direct path to overbooking. If you work with SAMO partners, see how we keep availability and stop-sale data in sync on our SAMO integration page. Finally, reporting suffers: the sales of one hotel are split across several records, and you can no longer see how the hotel really performs.

How hotel mapping works: three layers

Hotel mapping means linking every supplier's record to one master hotel in your system. In practice, it happens in three layers.

The first layer is the hotel itself. Names are normalized by removing words like "Hotel", "Resort" and "Spa", ignoring capitals and punctuation, and comparing what is left. Coordinates are compared by distance, and addresses, phone numbers and email domains add more evidence. Industry identifiers help too: many suppliers deliver GIATA IDs, a widely used standard for hotel identification, which makes a match much more reliable when both sides have one.

The second layer is the room type, and this is where most projects underestimate the work. "DBL SV", "Double Room Sea View" and "Superior Room with Sea View" may all be the same room, or they may not. Room names carry the room category, the view, the bed type and sometimes the occupancy, and every supplier writes them in its own way. A hotel that is mapped correctly but has unmapped rooms still cannot show a clean price comparison.

The third layer is the board type. One source sends "AI", another "ALL" and a third "All Inclusive". Ultra all inclusive, half board and bed & breakfast have their own variations. Board codes are a short list, but every mismatch here produces a wrong offer.

Automatic matching or manual review?

At scale, matching must be automated. A typical approach gives every candidate pair a confidence score based on name similarity, distance and shared codes. Pairs above a high threshold are matched automatically, pairs below a low threshold are rejected, and everything in between goes to a review queue.

Human review is still necessary, because a wrong match is more expensive than no match. Two different hotels with similar names on the same street, merged into one record, mean wrong prices and wrong bookings. An unmatched hotel only means a duplicate in the list.

Mapping is also not a one-time project. New hotels are added every week, suppliers change their content, and hotels rebrand. A mapping process needs a daily routine: new records are matched as they arrive, and the review queue is kept short.

Mapping belongs in the integration layer

The best place for mapping is the integration layer, between your suppliers and your sales channels. Mapping tables should be kept in one central place, not rebuilt for every new connection. When you add a new supplier, its hotels are matched against the same master list, and the new prices immediately compete with existing ones in the same hotel record.

This also works well with caching. Mapped content and prices can be calculated once and stored in a cache, so searches stay fast and suppliers are not flooded with requests. We explain the business case in Cache is Cash!. If you connect to incoming agencies, the choice between live and cached connections also affects where mapping runs; see SAMO Incoming Connections: Dynamic vs. Hybrid Integration.

A checklist before you start

• Measure the problem: how many sources, how many hotels and how many likely duplicates do you have?
• Decide who owns the master hotel list and which source wins when data conflicts.
• Build a dictionary for room and board codes, not just for hotels.
• Define a daily process for unmatched and low-confidence records.
• Track mapping quality over time, for example the share of hotels with more than one active source.

Clean inventory with Kharon

Kharon builds integrations and software for tour operators that buy from many sources, including SAMO and Sejour connections. If duplicate hotels are slowing down your sales or your operations team, we can design a mapping layer that fits your systems as part of our custom software development work. Get in touch to talk about your inventory.