- A room type taxonomy is the controlled vocabulary that every supplier room record is normalized into. Room mapping needs it, because mapping needs something to map to.
- A working taxonomy has six fields: primary category, bed configuration, view, smoking policy, occupancy and (where it matters) floor position.
- Supplier labels cannot be your taxonomy. They change with every refurbishment and system migration. Your taxonomy must stay still while the mapping layer absorbs the change.
- Rebooking engines and AI booking agents both depend on structured room fields. Free text is invisible to them.
Your platform takes room data from 15 suppliers. Look at one hotel.
Supplier A sends “Superior Double with City View”. Supplier B sends “Deluxe Double Room, Urban Outlook”. Supplier C sends a code: “RM_TYPE_2142”. Supplier D sends “Classic Comfort Room, Double”.
All four are the same physical room. Your property page shows four different rooms.
The guest cannot tell them apart. They book the cheapest without confidence, or they leave.
The fix is a room type taxonomy: a controlled vocabulary of categories, labels and attributes that all supplier room data is normalized into. It is also what makes room mapping possible. Mapping needs something to map to. The taxonomy is that something.
This guide is for OTA data leads and product managers who own room data. If you need the basics first, start with what hotel mapping and room mapping are.
What does a room type taxonomy contain?
Six structured fields, each with a closed list of values, cover almost every room you will sell.
1. Primary category
This is the top-level class. It sets the tier. A standard vocabulary looks like this: Standard, Superior, Deluxe, Junior Suite, Suite, Villa, Apartment, Hostel.
Every room should fit one of these. Many will not fit cleanly. Several European chains use “Classic”, “Prestige” or “Privilege”. Your taxonomy needs a rule for each. Decide once, write it down, apply it everywhere.
2. Bed configuration
Bed type and bed count, as structured values. Standard vocabulary: Single, Twin (two single beds), Double (one double bed), Queen, King, Bunk (for hostel and budget stock).
Watch regional convention. “Twin” in the UK often means two single beds that may be pushed together. In Japan it usually means two separate beds. Here the resolution rule matters as much as the vocabulary.
3. View descriptor
The room’s outlook, as a closed list: No view, Courtyard view, Garden view, City view, Pool view, Sea view, Ocean view, Mountain view, Lake view.
“Sea glimpse” and “partial ocean aspect” are not taxonomy values. They are free text. Your normalization rule should resolve them to the closest structured value and attach a confidence flag, so a reviewer can see which records were a stretch.
4. Smoking policy
Two values. Smoking or Non-smoking. Not a description. Not a note. Two values only.
5. Occupancy
Maximum adults and maximum children, as two separate whole numbers. A room that “sleeps 4” is ambiguous. Four adults, or two adults and two children? The guest needs the answer before they book.
6. Floor position
Low (floors 1 to 3), Mid (floors 4 to 7), High (floor 8 and above). This matters for towers and resorts, where height changes the value of the room. Most properties do not need it. Mark it as a conditional field.
| Field | Type | Allowed values | Common trap |
|---|---|---|---|
| Primary category | Closed list | Standard, Superior, Deluxe, Junior Suite, Suite, Villa, Apartment, Hostel | Chain labels such as Classic, Prestige, Privilege |
| Bed configuration | Closed list plus count | Single, Twin, Double, Queen, King, Bunk | “Twin” means different things in different markets |
| View | Closed list | No view, Courtyard, Garden, City, Pool, Sea, Ocean, Mountain, Lake | Free text such as “sea glimpse” |
| Smoking policy | Binary | Smoking, Non-smoking | Policy buried in a description |
| Occupancy | Two integers | Max adults, max children | “Sleeps 4” with no split |
| Floor position | Conditional list | Low, Mid, High | Applied to properties where it adds nothing |
Why can’t you use supplier room taxonomies directly?
Every supplier has its own room taxonomy. Some are well structured, with clean field-level data. Many send room type as one text string with no fields at all. None of them agree with each other. Without a normalization layer, they cannot be combined.
Some teams adopt their biggest supplier’s labels as the house taxonomy. It works until the supplier renames its rooms, which happens all the time: after a refurbishment, a rebrand or a system migration. Each time, your taxonomy changes with it. Labels that guests booked and trusted last month now read differently. Filter queries that worked last week return different results this week.
If your taxonomy changes every time a supplier changes, it is not a taxonomy. It is a feed output.
A well designed taxonomy is stable. Suppliers rename rooms, the mapping layer resolves the new label to the existing entry, and your guests and filters never notice.
How do you design a taxonomy that works at scale?
Three principles separate taxonomies that hold up from ones that collapse after the fifth supplier.
Principle 1: start from guest filters, not supplier names
Ask what guests filter on. Bed type. View. Smoking policy. Occupancy. Price. These are the attributes your taxonomy must hold as structured fields.
Internal supplier codes, renovation year and floor material do not belong. Keep the taxonomy lean. Every field you add is a field you must fill for millions of records.
Principle 2: design for completeness, not elegance
Every room type that appears in any supplier feed must fit somewhere in your taxonomy. If a room cannot be classified, it gets stored as a free-text exception.
Free-text exceptions are invisible to filter queries, AI booking agents and rebooking engines. Each one is a gap in coverage.
Principle 3: write resolution rules, not just a vocabulary
A vocabulary tells you the allowed values. A resolution rule tells you how to get there from a label you have never seen.
For example: “Classic Room” maps to Standard with a confidence score of 0.85. Records above your auto-accept threshold go live. Records in the uncertain band, say between 0.7 and your auto-accept line, go to a human reviewer. Records below 0.7 are held, not guessed. You set the thresholds. The point is that every unmatched label has a defined path.
Resolution rules let automated normalization handle supplier variation without a person reviewing every record.
| Supplier label | Category | Bed | View | Smoking | Action |
|---|---|---|---|---|---|
| Superior Double with City View | Superior | Double | City view | Non-smoking | Direct match, auto-accept |
| Deluxe Double Room, Urban Outlook | Superior (per property rule) | Double | City view | Non-smoking | Rule match, auto-accept |
| Classic Comfort Room, Double | Standard or Superior | Double | Not stated | Not stated | Medium confidence, send to review |
| RM_TYPE_2142 | Resolve from supplier code table | From attributes | From attributes | From attributes | Hold until code table is mapped |
The results are measurable. Vervotech customer Tripjack recorded a 30% increase in conversion rate after implementing room mapping. Fewer duplicate rooms on the page. More travelers who book.
How do you maintain a taxonomy as suppliers change?
A taxonomy is not a one-time deliverable. It is an operational discipline.
Suppliers rename rooms. Hotels rebrand categories. New suppliers bring new conventions. New property types appear (serviced apartments, glamping, apart-hotels) and may need taxonomy extensions.
Set a maintenance trigger
Any feed update that brings in a room label your taxonomy does not know should surface for review. Two things must not happen.
- The new label must not be silently auto-mapped to the nearest category without a confidence check.
- The new label must not be silently dropped.
Both erode coverage with no visible signal.
Run a quarterly label review
Once a quarter, pull the distribution of every room label in your supplier feeds. Sort by frequency. Flag any label that appears more than 100 times without a direct taxonomy match.
These are the gaps most likely to be distorting filter results and recommendations. Fix the top of the list first.
Extend deliberately
When a new property type needs new values, write the definition and the resolution rules, backfill existing records, and tell every team that queries room data. A taxonomy that grows without governance turns back into free text.
Taxonomy coverage is also one of the first things to check when you audit your mapping accuracy, and one of the first things to slip when you add suppliers and markets quickly.
Why does room taxonomy matter for rebooking and AI booking?
Rebooking needs proven room equivalence
A rebooking engine moves a confirmed booking to a cheaper rate for the same room. Before it substitutes, it must confirm equivalence.
“Superior Double with City View, Non-smoking” equals “Deluxe Double, Urban Outlook, Non-smoking” only if both resolve to the same taxonomy entry with matching attributes. Without a taxonomy, the engine falls back to name similarity. Name similarity produces false matches. False matches move guests into rooms they did not book.
A rebooking that saves margin and loses the guest’s sea view is not a saving. It is a complaint with a delay.
This is why room mapping and rebooking work best as one stack. The taxonomy is the shared language. The margin multiplier stack explains how the two compound, and Profit Maximizer is built on that room-level match.
AI booking agents need structured fields
On August 27, 2026, Google started rolling out hotel booking inside AI Mode in the U.S. (Vervotech’s guide to AI-driven booking). The agents behind these results match a user’s preferences to a specific room. King bed. Sea view. Non-smoking. Room for two adults and one child.
They need taxonomy fields to do that. “Spacious room with partial ocean aspect” is easy for a person to read and hard for an agent to trust. A view field set to “Ocean view” is something an agent can query. Unstructured rooms risk being misread or skipped.
Where should you start?
- Write the six fields and their value lists. Use the table above as a first draft.
- Pull your room labels by frequency. Every supplier, every property.
- Write resolution rules for the top labels, with thresholds for auto-accept, review and hold.
- Measure coverage: the share of room records that resolve fully, with no free-text exceptions.
The hard part is not the design. It is applying the rules to millions of records from hundreds of suppliers, every day. That is the job a room mapping API does: it reads supplier names and attributes, resolves them into one canonical room per property, and flags what it cannot resolve with confidence.
The takeaway
A room type taxonomy is unglamorous infrastructure. Nobody outside the data team sees it. Yet it decides whether your search filters are accurate, whether your rebooking substitutions are safe, and whether AI booking agents can read your rooms at all.
OTAs with a stable, maintained taxonomy have room data that works in every channel. The rest store room data their own systems cannot reliably query.
Send us a sample of your supplier room feeds. We will show you the duplicates, the free-text gaps and how each room resolves.
Frequently asked questions
What is a room type taxonomy?
A room type taxonomy is a controlled vocabulary for hotel rooms. It is a fixed set of categories, labels and attributes, such as primary category, bed configuration, view, smoking policy and occupancy, that every supplier room record is normalized into so the same room is described the same way across suppliers.
How is a room taxonomy different from room mapping?
The taxonomy is the target structure. Room mapping is the process that reads each supplier room record and resolves it into that structure. Mapping needs a taxonomy to map to, and a taxonomy is only useful if mapping keeps it filled.
Which fields should a hotel room taxonomy include?
Most OTAs need six fields: primary category, bed configuration, view, smoking policy, maximum adult and child occupancy, and floor position as a conditional field for towers and resorts. Each field should use a closed list of values, not free text.
Why not use a supplier’s room names as the taxonomy?
Supplier room names change after refurbishments, rebrands and system migrations. If your taxonomy follows them, your labels and filter results change too. A stable taxonomy lets the mapping layer absorb supplier changes without affecting guests or downstream systems.
How does room taxonomy affect rebooking and AI booking?
Rebooking engines must confirm two rooms are equivalent before moving a booking, and that needs matching taxonomy entries rather than similar names. AI booking agents match guest preferences to structured room fields, so rooms described only in free text may be misread or skipped.
