Breakfast Consistency Across Hotel OTA Listings

A breakfast audit that compares a single yes/no value will produce confident findings that are wrong. The field is really four: whether the property serves breakfast at all, whether it is included in the rate a particular listing is showing, what it costs when it is bought separately, and when and how it is served. A listing can be internally consistent on all four and still disagree with another channel on one.

Structured lodging models treat these separately. Google's lodging schema defines distinct values for breakfast availability, free breakfast, and buffet breakfast, which is a useful confirmation that the underlying data model expects them to be maintained independently rather than derived from one another.

Audit the four facts separately, and record which of them each channel actually exposes as a structured field. Where a channel has no field for a fact, the fact will live in policy text and needs comparing as text.

This is the single most misdiagnosed finding in a breakfast audit. Whether breakfast is included is a property of the rate plan being displayed, not of the hotel. Booking.com documents attaching meals to specific rate plans, or offering them as a paid add-on with a price. A property can therefore publish a breakfast-included rate on one channel and a room-only rate on another and be entirely correct on both.

That makes the comparison harder than it looks. Two listings showing different inclusion values are only in conflict if they are describing the same rate plan. Before recording a finding, establish which rate plan each public page was showing at the moment the evidence was captured — and note that this can change with the dates and occupancy searched.

The genuine errors in this area are narrower and worth isolating: a rate plan whose name promises breakfast while the meal is not attached, a breakfast-included plan published on one channel only when it was meant to be everywhere, or an add-on price left at an old value.

• Compare inclusion only between listings showing the same rate plan.
• Record which rate plan each captured value came from.
• Check that a rate-plan name promising breakfast actually has the meal attached.
• Treat an inclusion difference across different rate plans as a scope difference, not a conflict.

An amount alone does not tell a guest what they will pay. Breakfast is usually charged per person per day, but it is sometimes quoted per room, sometimes with a separate child rate, and sometimes with children below an age free. A family of four reading a single adult price has not been given the information they need.

Tax treatment is worth recording too, because it determines whether the published figure is what the guest pays. Where the platform expects a tax-inclusive figure and your source of truth holds a net price, the conversion needs doing once, in the source of truth, rather than repeatedly and inconsistently by whoever edits a listing.

When comparing channels, treat amount, currency, basis, and child policy as separate values. A channel with the right amount and the wrong basis is a real finding, and it is the one most likely to surface at the desk as a dispute.

• ✓Publish amount, currency, and basis together.
• ✓State the child price or the age below which breakfast is free.
• ✓Record whether the published figure includes tax.
• ✓Check a worked example — two adults, one child, two nights — against what the desk would charge.
• ✓Keep the exact public wording beside any normalised value.

Breakfast drifts more than most fields because more people can change it. Food and beverage sets the hours and the type, revenue management attaches the meal to rate plans, and marketing bundles it into a promotion. Each of those changes can reach the public listings through a different route, and only one of them usually comes with a checklist.

The promotional bundle is the most reliable offender. Breakfast is included in a campaign rate for a season, the campaign ends, and the rate plans are unwound on the channels the campaign ran on — but the property-level breakfast attribute, edited at the same time, is left as it was. The listing then advertises free breakfast the property stopped offering.

Seasonal service changes create the same pattern in reverse. A property that reduces to a continental offer out of season, or moves breakfast hours an hour later, should treat the listing update as part of the operational change rather than a separate task that may not happen.

• A promotion bundles breakfast and the property-level attribute is never unwound.
• Hours change seasonally and reach some channels only.
• The type changes from buffet to continental without the listings following.
• An add-on price is updated in one extranet and left stale elsewhere.
• A rate plan is republished and loses its attached meal.

Because inclusion depends on the rate plan, the capture step matters more here than in other fields. Search the same dates and occupancy on each channel, record the rate plan alongside the value, and only then compare. An audit that captures different search parameters per channel will generate conflicts that do not exist.

Correct at the interface that owns each fact — the meal plan for inclusion, the property attributes for availability and hours, the add-on configuration for price — and verify the public result afterwards. A saved rate plan is not evidence that the public page now shows the meal.