Hotel Board Basis and Meal Plans Across OTAs

Room only, bed and breakfast, half board, full board, all-inclusive. These read like descriptions of a hotel and they are not - they are descriptions of a rate plan. The same property can legitimately sell a room-only rate, a bed-and-breakfast rate, and a half-board rate on the same night, and whichever one a channel happens to display becomes the board basis a guest believes the hotel offers.

Booking.com makes the split explicit in where it puts the settings: a meal payable by guests on arrival is configured under the property's facilities and services, with a price per person per day, while a meal included in a specific rate is configured in the meals row of that rate plan under rates and availability. Those are two different screens expressing two different facts, and both can be true at once.

This is why the board-basis audit has a step the other field audits do not. Before comparing anything, establish which rate plan each public page was displaying when the evidence was captured - and note that this can change with the dates, occupancy, and length of stay searched. Skip that step and the audit manufactures conflicts out of a property doing nothing wrong.

• A board code describes a rate plan, so two channels can disagree and both be right.
• Booking.com splits meals into a property-level price on arrival and a rate-level inclusion.
• The displayed plan can change with dates, occupancy, and length of stay.
• Record the rate plan beside every captured board value, or the comparison is not meaningful.
• The real errors are narrower: a plan whose name promises a meal that is not attached to it.

Board basis is unusual among listing fields in that the structured data runs out in the middle. Google's lodging schema carries fields for whether breakfast is offered to all guests, whether it is free, whether it is a buffet, and whether the property has an all-inclusive rate option or sells all-inclusive only. It carries no field for half board, full board, demi-pension, lunch inclusion, or dinner inclusion. Expedia Group's content reference lists, which document amenities, attributes, categories, payment types, and several other lists, document no meal-plan reference list at all.

So the two ends of the range are structured and the middle is not. A property selling room-only or all-inclusive can express that in data. A property selling half board has to express it in a rate-plan name, a description, or policy text - which is to say, in prose that no automated comparison and no guest-facing filter can read reliably.

That is the mechanical reason half board is the least consistently published board code, and it is worth stating plainly to anyone who asks why their dinner-inclusive rate keeps being misunderstood. The data model does not have a place to put it. The practical response is to write the inclusion into the rate plan name and the description in consistent words, decided once, and to treat that wording as a field under change control rather than as copy.

Note what does exist in data: Booking.com's accommodation details return meal prices for breakfast, lunch, and dinner. Prices for the individual meals are modelled even where the board code combining them is not, which gives you somewhere consistent to put the lunch and dinner facts even on a channel that cannot express full board.

Two channels can publish the identical words 'half board' and still be selling different things. Half board normally means breakfast plus one other meal, but which meal, whether drinks are included, whether it covers the departure day, and whether children are charged differently are all unstated by the code itself. A guest who books half board expecting dinner with a drink and finds dinner without one has been misled by a listing that was perfectly consistent.

So the approved record needs to carry more than the code. Decide and write down which meals are included, the basis on which they are charged or credited, what happens on arrival and departure days, whether a drinks allowance is part of it, what the child basis is, and which venue serves it. Then publish those details in the same words everywhere, so the comparison across channels is a comparison of the same statement.

Where a channel has no field for any of this, it goes in the description. That is not a workaround to apologise for - it is the only place the information can live on a model that stops at breakfast, and it is far better than letting the desk explain it on arrival.

• ✓State which meals the code includes, by name.
• ✓State the basis: per person per night, and the child basis separately.
• ✓State what happens on the arrival and departure days.
• ✓State whether any drinks are included, and which.
• ✓State the venue, and the serving times if they are restricted.
• ✓Publish the same wording on every channel and keep it under change control.

The dominant cause is the promotion that is only half unwound. A dinner-inclusive package runs for a season, the campaign ends, and the rate plans are retired on the channels the campaign ran on - but the property-level meal attribute, edited at the same time and owned by somebody else, stays as it was. The listing goes on describing a board basis the property stopped selling.

Seasonal operation produces the same drift in the opposite direction. A resort that sells half board in winter because the nearest restaurant is closed, or a city hotel that drops dinner service out of season, is making a real operational change that needs to reach the listings as part of the change rather than as a separate task that may not happen.

The third pattern is quieter and specific to this field. Because half board has no structured home, its wording lives in a rate plan name typed by hand - so it gets retyped, abbreviated, and translated inconsistently across channels over the years. Nobody made a mistake; the field simply has no single value anywhere to be the one that is right.

• A package ends and the rate plan is retired while the property-level meal attribute is not.
• Seasonal service changes reach some channels and not others.
• Hand-typed rate plan names diverge across channels because no structured field holds the code.
• A rate plan is republished and loses its attached meal.
• An all-inclusive attribute is set at property level while only some rate plans are actually all-inclusive.

Fix the search before capturing anything: the same dates, the same occupancy, the same length of stay on every channel. Then record the board code, the rate plan it belongs to, the exact wording, and the URL. Only with the rate plan recorded can you tell a conflict from a scope difference, which is the distinction this field lives or dies by.

Correct at the interface that owns each fact - the rate plan for inclusion, the property settings for a meal price payable on arrival - and verify the public page afterwards. A saved rate plan is not evidence that the public page now describes the meal.