Hotel Property Type and Category Across OTAs

Most listing audits start with amenities and policies. The classification sits a level above those, because it decides which of them a channel will ask you about at all. An apartment category will offer kitchen fields and may not ask about reception hours; a hotel category will ask about meal plans and front-desk service and may have nowhere to record a washing machine. The audit finding 'kitchen facilities missing' can therefore be a classification problem wearing an amenity costume.

This is visible in the interfaces as well as in the data. Agoda's published facilities guidance gives its navigation specifically for hotel-type properties, which is a small but telling detail: the classification does not merely label the property, it changes the screens the operator is given. An operator following instructions written for a different type will not find the fields being described.

So audit the category first and the fields second. A cluster of unrelated-looking gaps across several channels frequently resolves to one wrong classification, and correcting the classification fixes them together.

• The category determines which fields the channel offers.
• A missing field may mean the channel never asked, not that you failed to answer.
• Interfaces differ by type, so generic instructions may not match your screens.
• Audit classification before field-level comparison, or you will chase symptoms.
• Record the category each channel holds for you as part of your source of truth.

Expedia Group's content reference lists document a category list that classifies property types, where each property has exactly one category designation carrying an id and a name. The published examples run from hotel, motel, resort and inn through bed and breakfast, guesthouse and hostel, to villa, cabin, cottage and chalet, apartment, condo and vacation home, and on to specific types such as castle, palace, ryokan, tree house and capsule hotel.

Booking.com's accommodation details return an accommodation type as a numeric identifier, alongside the name, location and contacts. Google's lodging schema, by contrast, carries no property-type field at all - the nearest thing it has is a class rating, which is a one-to-five classification based on services and facilities and answers a quite different question from what kind of property this is.

The practical consequence is that property type cannot be reconciled across channels the way a check-in time can. There is no shared vocabulary and, on one major model, no field. What you can reconcile is the consequence: whether each channel's classification lets you publish the facts your property actually has.

The constraint that each property has exactly one category is where hybrid properties run into trouble. An aparthotel is a hotel with kitchens; a guesthouse with a restaurant is part hotel; a hostel with private rooms is both. Each has to be classified as one thing, and whichever is chosen will be slightly wrong - the question is which error costs less.

Choose by what the guest is buying rather than by what the business calls itself. If the defining feature is a kitchen and a longer stay, the apartment-family category will ask the right questions and show the right filters, even if your signage says hotel. If the defining feature is daily service and a front desk, the hotel category is the honest one even when every unit has a kitchenette.

Then compensate deliberately in text for whatever the chosen category cannot express. A property classified as a hotel should describe the kitchens prominently; one classified as an apartment should describe the reception and the daily service. The category sets the frame, and the description is where you fill in what the frame left out.

• ✓Decide the category by what the guest is primarily buying.
• ✓Record the chosen category per channel in your source of truth.
• ✓List what that category cannot express for your property.
• ✓Describe those things explicitly in the description on that channel.
• ✓Re-check after any change that shifts the property's character, such as adding kitchens or removing a restaurant.

Classification is usually set during onboarding, often by whoever created the listing, and it is frequently not something an operator can change from the extranet afterwards. That makes a wrong category different from a wrong amenity: it is a request with an owner and a waiting period rather than an edit you can make this afternoon.

Treat it accordingly. Record the correct category, raise it with each channel through their support route, and note the date you asked - because the symptom you were originally chasing, such as a missing field or an odd filter result, will persist until the classification changes, and somebody will otherwise re-report it as a new problem next quarter.

In the meantime, do the compensating work in the description. A property miscategorised as an apartment can still describe its reception, its breakfast and its daily housekeeping in words, and a guest who reads the page will get the right picture even while the structured data is wrong.

• Record the correct category and the date you requested the change.
• Keep the request open against each channel rather than closing it as unactionable.
• Describe in text what the wrong category prevents you from publishing structurally.
• Expect downstream symptoms to persist until the classification itself changes.
• Re-audit the affected fields after a category correction lands.

Read the category each channel has assigned you, write them side by side, and compare them to the one you would choose. Then ask, for each channel, whether the fields you need are available to you - that is the real test, and it is more useful than arguing about which label is most accurate.

Where a classification is wrong, raise it; where it is right but limiting, compensate in the description. Re-check after any structural change to the property, because the category that was correct for a hotel with a restaurant may no longer be correct once the restaurant closes.