Hotel Airport Shuttle and Transfers Across OTAs

Google's lodging schema separates the idea of a transfer - a shuttle service to the nearest airport or train station - from an airport shuttle specifically, described as a chauffeured van or bus to and from the airport, and then carries a third field for whether that airport shuttle is free. Three fields, and the one that matters most to a guest comparing hotels is the third.

That separation is the same pattern that makes Wi-Fi unreliable, and it fails the same way. A property with a paid shuttle ticks the service and leaves the free flag alone, which is correct. A property with a paid shuttle ticks the service on a model that treats amenities as complimentary unless a surcharge is specified, and has now published a free shuttle it does not run. Nobody typed the word free.

Audit the charge explicitly, on every channel, every time. The service flag will almost always be right because somebody set it deliberately; the charge is the one that drifts by omission.

The structured data tells a guest that a shuttle exists and perhaps that it is free. It does not tell them that it runs 06:00 to 22:00, that it needs 24 hours of notice, that it leaves from a specific pillar at a specific terminal, or that it is one-way. Those facts are the difference between a service and a promise, and none of the reviewed models has a field for any of them.

This matters more for shuttles than for most fields because of where the failure happens. A guest who misreads a breakfast price finds out at breakfast. A guest who assumes a shuttle runs on demand at midnight finds out at an airport, at midnight, with the hotel's phone going to voicemail. The listing was not false; it was incomplete in the specific way the model encourages.

The response is the same discipline the arrival paragraph needs: write one canonical description of the service, including every condition, and publish that same text on every channel that offers a box for it. Where a channel offers a facility detail or policy field that can carry the conditions, use it in addition to, not instead of, the description.

• ✓Write one canonical shuttle paragraph covering hours, direction, notice, and pick-up point.
• ✓State the charge in words even where a free flag exists.
• ✓Name the airport explicitly where more than one serves the city.
• ✓Say whether the return leg is included or booked separately.
• ✓Publish the same paragraph on every channel and keep it under change control.

Agoda's published facilities guidance notes that key facilities such as free Wi-Fi and airport transfer are automatically featured in the highlights section of the guest-facing property page. That is a useful illustration of a general behaviour: a structured amenity is not just data, it is promotional surface, and channels promote the amenities they know travellers filter on.

So the consequence of a loosely set transfer flag is larger than a wrong value in a table. It can become one of the handful of phrases shown prominently to someone deciding between properties, and it will carry none of the conditions that make it accurate. A property that offers a paid, weekday-only, book-ahead shuttle can find 'airport transfer' presented as a reason to book.

The practical rule: set the structured flag only where the service is available to any guest without unusual conditions, and carry everything conditional in the text. An unticked box with a clear paragraph serves a guest better than a ticked box they will discover was qualified.

• Structured amenities can be promoted automatically into highlights and filters.
• Filters have no room for conditions - they are true or false.
• Set the flag for the unconditional case; describe the conditional one.
• Check how each channel renders the flag on the live page, not just how it stores it.
• Treat a promoted badge as a promise the desk will have to keep.

Shuttles are frequently the first service to be cut and the last listing to be updated. A vehicle comes off the road, a driver leaves, a contract with a transfer company ends, or the service is reduced to peak season - all operational decisions, none of which arrive with a list of listings to amend. The amenity, meanwhile, sits ticked on five channels where somebody set it years ago.

Seasonality is the other recurring pattern, and it is harder because the honest value changes twice a year. A resort running a summer airport service and nothing in winter has no way to express that in a boolean, so whichever value is set is wrong for half the year. Where that is the situation, the service flag should reflect the off-season and the description should carry the seasonal dates, because overstating is the more expensive error.

Third-party operation adds a second owner. Where the shuttle is run by a transfer company, changes to its timetable are changes to your listing, and nobody at the transfer company knows that. Put a review of the published text into whatever contract review you already do.

• The service is withdrawn or reduced and the amenity stays ticked.
• A seasonal shuttle is published as a year-round one.
• A third party changes the timetable and nobody updates the listings.
• The charge is introduced and the free flag is never revisited.
• A terminal moves or a pick-up point changes and the instructions do not.

Read each live listing and write down what a guest would believe about the shuttle after reading it - not what the fields are set to, but what the page says as a whole, including any badge the channel added. Compare those beliefs to the service you actually run today, and note which channels overstate it.

Then correct in both places: the structured flags, and the canonical paragraph. Verify the public pages afterwards, including the highlights or badges area, because that is where a corrected field can keep showing an old promotion for longer than you expect.