Naming room types: one name that the property system, the channels and the door sign all share

A room type naming sheet gives every sellable room exactly one internal code and one guest-facing name, then records how that name appears in the property system, each channel and on the door. The code stays fixed for the life of the room type; the guest-facing name may change, but only through a controlled rename.

A guest books a room called "Deluxe Garden View", receives a confirmation with that name, and opens a door whose sign says "Standard Double". Nobody lied; three systems simply held three names for the same room. Hotel room type naming in the property system, at the channels and on the door is usually treated as three small editing jobs done by three different people. This guide turns it into one controlled document: a naming sheet with one code and one guest-facing name per room type, a safe rename procedure, and a door sign that agrees with the confirmation.

Why does one room end up with three different names?#

Because three different systems hold the name for three different purposes, and nothing in the hotel forces them to agree.

The property system needs a short, stable code that staff type and reports group by. It is built for machines and for people who already know the building, not for guests. Each channel holds its own room type record with its own title, its own identifier and its own field rules; the link between that record and the hotel's code lives in the channel manager, not in the name. Marketing writes a third name for the website and the campaign, usually rewritten by whoever has the copy that season.

Drift happens because the three are edited at different times by different people. The code is set once and never touched. Channel titles are edited by whoever is on duty. Website copy changes with every campaign. Nothing checks the three against each other, so they move apart quietly.

The cost lands at the desk. A guest who booked "Deluxe Garden View" and opens a door marked "Standard Double" is not wrong to complain, and the front desk has no document to check against. The same drift breaks revenue work: two channel titles mapped to one code, or one title mapped to two codes, is one of the ways the same physical room gets sold twice, as covered in how double bookings across channels happen and how to prevent them. It also breaks reporting: a name changed mid-season splits one room type into two lines, and a year-on-year comparison quietly compares two different things.

What should a room type naming sheet contain?#

One row per sellable room type, carrying a fixed internal code, the guest-facing name in every language you sell in, and the physical attributes the guest is actually buying.

The internal code is short, uppercase, without spaces, and derived from the product (bed type and view), never from the price or the season. It is the one field that never changes. The guest-facing name exists in each language you sell in, written as the exact string that will appear on the website, on the confirmation and on the door sign.

Physical attributes matter because they are what the guest can check: bed setup, view, measured size, maximum occupancy including children, and whether the room connects to another or is accessible. Size is measured on site, not copied from a brochure or an old rate sheet; a wrong size written into a name is a complaint waiting to happen.

Give the sheet one column per channel, so a mismatch is visible on a single page instead of being discovered by a guest at the door. Include the door sign text, which is often shorter than a channel title and must still be recognizably the same room. Finally, add a retirement rule: a code whose rooms no longer exist is marked retired, never deleted, because past reservations, invoices and reports still point at it.

The sheet, column by column#

The example below shows the shape of the sheet, not a real hotel's products.

All rows are for example. The full sheet adds columns for the second language, the view, the measured size, each channel's title and the door sign text, and it ends with a blank row marked "add one row per sellable type, never per physical room". Maximum occupancy, including how children are counted, must match everywhere; see child ages across channels and how one rule keeps occupancy consistent.

What makes a guest-facing room name good?#

It describes the room the guest will actually get, in words a traveler can check against the room at the door.

Lead with the bed and the view: those are the two attributes guests compare first and complain about most. Avoid names that promise a feeling ("Premium Escape", "Signature Stay") instead of a product; they cannot be checked, so every small disappointment turns into a dispute.

Do not use a name to suggest a class the facility does not hold. A room name is not a classification and does not make a facility anything. Do not put the price, the season or the campaign into the name either; the name outlives the campaign, and the old name stays in confirmations already sent.

Translate rather than transliterate: the Turkish and English names must describe the same room, and a short glossary of the words you use stops two people inventing two spellings. Keep "suite", "family" and "connecting" for rooms that genuinely are; if the room types themselves are unclear, settle that first with a clear set of double, twin, triple, family and connecting room types.

How do you map the naming sheet to each channel?#

You map each channel's room type record to one internal code, once, and then treat the channel title as a copy of the sheet rather than a second original.

The mapping is normally held as an identifier rather than as text, which is why editing a channel title usually does not break the link, while deleting a room type and creating it again does. Each channel has its own rules on title length, allowed characters and content; read the extranet's field rules before writing, and never assume a channel will accept a name exactly as written.

Rate plans are separate from room types. "Breakfast included, non-refundable" is a rate plan name, and mixing the two is how a guest arrives believing they booked a different room. Maximum occupancy and child ages must match across the sheet and every channel, or the same room sells to different party sizes.

Keep the sheet as master: when a channel title and the sheet disagree, the sheet wins and the channel is corrected. After any mapping change, make a test booking and read the confirmation the way a guest reads it, not the way the extranet displays it. The mechanics of this are covered in channel manager mapping for room types, rate plans and testing.

How do you rename a room type safely?#

Change the words, keep the code and the mapping, do it in one quiet window, and prove it with a test booking on every channel.

First decide whether this is a rename or a new product: same bed, same view, same size means a rename; anything else is a new room type with a new code and a retired old one. Pick a low-pickup window; a rename during a campaign or a full house leaves no room to correct a mistake.

Change one thing at a time: if the name, the code and the rate plan links all move on the same day, you cannot tell which change broke what. Tell the front desk and housekeeping before the change goes out, and give them a one-page list with old and new names side by side for the first month. Keep a dated record of each rename: old name, new name, who approved it, when it went live, so a dispute months later can be settled from the record rather than from memory.

The rename, in order#

What about door signs, key cards and the printed room list?#

They are the last place the name appears and the first place the guest checks it, so they belong on the naming sheet from the start.

Door signs are physical and slow to change; order them only after the digital names have held for a season, or choose a format that can be reprinted cheaply. Key card sleeves, welcome folders and breakfast lists are printed in batches; check the stock before a rename, or you will be handing out the old name for months.

Operational lists should carry the code next to the guest-facing name, so staff can bridge old and new without guessing. In-house guests notice first: someone who checked in under the old name and sees a new sign on day three will ask, and the answer has to be ready at the desk. A rename must never change what the guest is entitled to; if the new words imply a view, a size or a service the room does not have, the guest has a fair complaint.

When should you review the naming sheet?#

Once a season, before contracts are signed, and whenever a physical change adds, splits or removes a room type.

Check that every sellable room type has exactly one row, and that every row still has rooms behind it. Look for codes with no rooms left and for channel titles that no longer match the sheet. Retire rather than delete: past reservations, invoices and reports point at old codes, and a deleted code leaves a hole in the record.

Compare the sheet against what the front desk actually says at check-in; the desk is where drift shows first. Add a new room type only after the physical product exists, not before the refurbishment is finished. Groups need one more check: the same room type name must mean the same thing across the properties, or a comparison across hotels is comparing labels rather than rooms, as discussed in one report across several hotels and what must stay separate.

What to do next#

Build the first version of the sheet this week. Export the room type list from the property system, give each type one row, and check three things against it: one live channel title, one confirmation email and one door sign. Where they disagree, you have found the drift, and the sheet is now the document that settles it. From then on the rule is simple: the code never changes, the guest-facing name changes only through the ordered rename, and the door sign is part of the decision, not an afterthought.