When Travel Ferry, part of the Giovanti Travel group, set out to modernise how travellers book Greek island trips, the brief was both simple and rare: let one search return the ferry and the hotel that fits the same trip — and let the traveller pay for both in a single checkout. Together we built that experience on top of Boötes, our travel booking platform — and we now run both Travel Ferry's ferry booking engine and hotel booking engine from the same stack.

From two separate bookings to one journey

Until recently, planning an island trip meant juggling two flows: a ferry on one site, a hotel on another, then re-checking dates and ports to make the pieces line up. That friction is exactly where bookings are lost. Travel Ferry wanted a single, calm flow — pick a route, pick a hotel on the destination island, pay once, get one confirmation.

Delivering that meant the ferry booking engine and the hotel booking engine had to behave as one product, not two. Boötes was already powering Travel Ferry's ferry availability across multiple distributors — we extended the same engine to host their hotel inventory, and stitched the two together at the funnel level so the user only ever sees a single trip, not two transactions.

Ferry + hotel, integrated in the same flow

The result is a true dynamic packaging experience. The ferry leg drives the hotel search, the hotel leg respects the ferry's arrival and departure windows, and the price the traveller sees is the bundle.

  • One search, two products. Ferry availability and hotels on the destination island are returned together for the dates the traveller picked.
  • One cart, one payment. Ferry tickets and accommodation are paid in a single transaction, with one confirmation email covering both.
  • Date-aware hotels. Check-in and check-out default to the ferry arrival and return — the user never has to retype dates the system already knows.
  • Bundle pricing. Combined ferry-and-hotel options unlock package-level offers that aren't available when the two are sold separately.
  • Single back-office. The agency manages reservations, payments, and reporting for both products from one dashboard.

Why we also delivered the hotel side

Owning both the ferry and the hotel booking engine is what makes the integration feel native instead of bolted-on. When a third-party hotel widget is dropped into a ferry site, the experience shows it: separate baskets, separate sessions, mismatched dates, double payments. By delivering Travel Ferry's hotel booking engine on Boötes too, we kept the entire journey on a single state — one cart, one user, one record — and turned what is normally a clumsy hand-off into one continuous funnel.

What's under the hood

Boötes is built to combine source APIs and surface them through one booking engine. For Travel Ferry that translated into:

  • Ferry inventory from leading Greek distributors Certus and Liknoss, normalised through the Boötes API.
  • Hotel inventory via onetourismo's hotel API, mapped against Travel Ferry's destination catalogue.
  • Dynamic packaging logic that combines ferry and hotel at search time — not at checkout — so the user never sees an unbookable bundle.
  • Unified payments and reporting through a single Boötes back-office, with one set of credentials, one ledger, and one reservation record per trip.

The architecture is intentionally modular. Ferry sources, hotel sources, payment gateways, and CRM connectors plug into Boötes independently, so we can add or swap providers without rebuilding the user-facing flow.

Why this matters for travel businesses

Most ferry booking engines stop at the ticket. Most hotel booking engines stop at the room. Travel Ferry asked us to remove the seam between them — and that seam is exactly where margin and conversion live. For an agency, dynamic packaging means higher basket value per session, fewer abandoned carts, and one back-office instead of three.

If you run a travel agency, DMC, or incoming tour operator and you're still selling ferry tickets and hotels through separate stacks, the Travel Ferry build is a useful template: one booking engine, two products, one payment — and a back-office that finally agrees with the front-end.

Curious how this would look on your own inventory? Explore Boötes or talk to us.