Why One-Size-Fits-All Platforms Fail Tourism Operators
Your ferry is not a hotel room. Your tour is not an airline seat. So why does your booking system treat them the same?
Somewhere in the history of travel technology, a decision was made that has shaped the industry ever since: build one platform, serve everyone. The logic was sound from a software economics perspective -- a single product serving hotels, car rentals, ferries, tours, and events is cheaper to develop and maintain than five separate ones. One codebase, one team, one roadmap.
The problem is that this logic optimises for the software company, not the operator. And operators are the ones who live with the consequences.
A ferry operator needs to model vehicle deck capacity in lane metres, manage dangerous goods segregation, coordinate multi-port timetables, and handle the complex interplay between passenger types and vehicle types on every sailing. A boutique tour company needs to track guide availability, equipment inventories, pickup point logistics, and group dynamics that change the nature of the experience. A dinner cruise operator needs to manage table configurations, dietary requirements, beverage packages, and the relationship between dining seatings and vessel capacity.
These are not edge cases. They are the core of how each business operates. And yet, the majority of booking platforms available to these operators treat all of them as variations of the same basic problem: put a number of people in a venue on a date.
This article examines why this approach fails, what it costs operators in practice, and what the alternative looks like.
The Diversity Problem: Fundamentally Different Businesses, Fundamentally Different Needs
The transport and tourism industry is remarkably diverse, but this diversity is often invisible to technology providers. To understand why one-size-fits-all platforms struggle, it helps to look at what "capacity" actually means for different operator types.
Ferry Operations: Where Capacity Is Multi-Dimensional
For a ferry operator, capacity is not a number. It is a complex, multi-dimensional constraint that reflects the physical reality of a vessel.
Passenger capacity involves seats in different classes (economy, premium, lounge), each with distinct pricing and amenities. But passenger capacity is also affected by vehicle deck bookings -- foot passengers and drive-on passengers consume different resources.
Vehicle deck capacity is measured in lane metres, not vehicle count. A 4.5-metre sedan, a 7-metre campervan, and a 19-metre truck all consume the same resource -- deck space -- but in dramatically different quantities. The deck also has height restrictions on certain lanes, weight limits per axle position, and regulatory requirements for dangerous goods segregation.
Weight capacity (tonnage) provides yet another constraint. A sailing might have lane metres available but be at its weight limit, or vice versa.
A generic booking system models this as "ferry capacity: 200 passengers, 40 vehicles." The reality is that the actual capacity of any given sailing depends on the specific mix of passengers and vehicles booked. Two identical vessels with identical "capacity" can accommodate completely different combinations of bookings.
When the system cannot model this complexity, the operator must manage it outside the system -- manually checking deck plans, calling customers to verify vehicle dimensions, and making judgment calls about whether to accept the next booking. Every one of these manual interventions is a cost the technology should be eliminating.
Tour Operations: Where Inventory Is Not Just a Number
Tour operators face a different but equally misunderstood set of capacity challenges. A generic booking system sees a tour as "20 available slots on March 15." The reality is far more nuanced.
Participant types affect capacity differently. A family kayak tour might count adults, children over 12 (who paddle their own kayak), and children under 12 (who share a tandem kayak with a parent). Each type consumes different equipment, affects safety ratios, and changes the dynamics of the experience. A generic system that treats all participants as equivalent will either over-count or under-count actual capacity.
Equipment is often the real constraint. If you have 20 participant slots but only 15 kayaks, your actual capacity is 15 for adults and unlimited for small children sharing -- unless three of those kayaks are tandems, in which case the calculation changes again. A generic system has no concept of equipment inventory linked to booking capacity.
Guide availability shapes the operation. Many tours have a maximum guide-to-participant ratio driven by safety regulations, quality standards, or permit conditions. If your ratio is 1:8 and you have two guides, your real capacity is 16 -- regardless of what the "slots available" number says. And if one guide is qualified for advanced trips and the other is not, the constraints differ by product variant.
Pickup logistics create hidden constraints. A tour with three pickup points needs a vehicle that can complete the route in time. If a booking at the furthest pickup point would extend the route beyond the available time window, that "slot" is not actually available -- but the booking system does not know this.
According to Tourism Research Australia, tour operators spend an average of 12 hours per week on manual coordination tasks that relate directly to gaps between their booking system and their operational reality. Over a year, that is more than 600 hours -- the equivalent of hiring a part-time staff member whose sole job is to compensate for inadequate technology.
Coach and Bus Operations: Where the Seat Is the Product
For coach operators, seat selection is not a nice-to-have -- it can be a core part of the customer experience and commercial model. Premium seats at the front or with extra legroom command higher prices. Groups want to sit together. Accessibility requirements dictate specific positions. And the operational reality of boarding -- which passengers board first, which aisle is used, where luggage is stored -- is intimately connected to seating.
A generic booking system typically offers seat selection as an add-on feature, if it offers it at all. The seat map functionality, when present, is usually designed for airline-style seating -- rows and columns of identical seats. Coach seating is different: upper and lower decks, tables, different orientations, wheelchair positions, and configurations that change between vehicle types in the fleet.
The commercial implications matter. Research from the International Road Transport Union (IRU) suggests that seat selection and seat-based pricing can increase revenue per departure by 5 to 12 percent for long-distance coach services. But only if the system can model the actual seat configuration of the actual vehicle assigned to the actual departure.
When operators cannot offer seat selection because their system does not support their vehicle configurations, they leave that revenue on the table. When they try to implement it using a generic seat map tool, they spend significant time managing the mismatch between the system's model and their real vehicles.
Cruise Operations: Where the Booking Is the Journey
Cruise operators -- whether multi-day accommodated cruises or single-evening dinner cruises -- face perhaps the most complex booking challenge of all. A cruise booking is not a single transaction. It is a journey that combines accommodation, transport, dining, activities, and often shore excursions into a single integrated experience.
Cabin categories in a multi-day cruise are not interchangeable hotel rooms. They have specific locations (deck, position), views (ocean, balcony, interior), configurations (double, twin, family), and amenities. Pricing varies not just by category but by departure date, duration, and itinerary.
Dining seatings need to be coordinated with cabin bookings. A 7 PM dinner seating on a 100-passenger vessel needs to accommodate the right number of covers, manage dietary requirements across the full voyage, and handle table assignments that affect the guest experience.
Shore excursions and add-ons need to be bookable as part of the cruise package or separately, with capacity that is independent of the vessel capacity. A 100-passenger cruise visiting a port where the local tour operator can only take 30 people creates a capacity constraint that exists outside the vessel but inside the booking.
A generic booking system treats each of these as separate products -- a cabin booking, a dining reservation, an activity ticket. The operator is then left to manually coordinate between them, ensuring that cabin 12's guests are in the right dining seating, have been allocated shore excursion spots that do not conflict with each other, and have dietary requirements flagged across every food service.
For dinner cruise operators, the challenge is different but equally specific. Table configuration matters: a vessel might seat 80 guests across tables of 2, 4, 6, and 8 -- but two couples who booked separately should not share a table intended for a birthday party of eight. Beverage packages, menu selections, and special occasion requests are all part of the booking, not afterthoughts. And the relationship between restaurant-style dining and vessel-style capacity (passenger counts, safety equipment) creates constraints that neither a restaurant booking system nor a transport booking system handles alone.
The Workaround Tax: What Generic Systems Really Cost
When a booking system cannot model your operation accurately, you build workarounds. Over time, these workarounds become standard operating procedure -- so embedded in daily routines that no one questions whether they should exist at all.
Here is what the workaround tax looks like in practice:
The shadow system. A spreadsheet, whiteboard, or paper document that tracks information the booking system cannot. Vehicle deck allocations. Equipment assignments. Guide rosters. Table plans. These shadow systems require manual updates, are prone to errors, and create a single point of failure if the person who maintains them is away.
The confirmation call. When the online booking flow cannot capture the information you actually need, someone has to call the customer. What size is your vehicle? Do you have any dietary requirements? What is your certification level? Each call costs time and creates friction that reduces customer satisfaction and increases the risk of cancellation.
The manual reconciliation. At the end of each day, week, or month, someone has to reconcile the booking system data with reality. Were the right people on the right departure? Did the capacity figures match what actually happened? Were the commissions calculated correctly? Manual reconciliation is slow, error-prone, and adds no value -- it simply compensates for systems that cannot do it automatically.
The institutional knowledge problem. When your operation depends on workarounds, it also depends on the people who know how those workarounds function. What happens when your most experienced reservations agent retires? When the operations manager who built the capacity spreadsheet moves to a different company? The workarounds are rarely documented because they were never supposed to be permanent. But they became permanent, and now they represent operational risk.
According to a Harvard Business Review analysis of technology workarounds in service industries, organisations typically underestimate the cost of workarounds by a factor of three to five. The visible costs (staff time, error correction) are compounded by invisible costs (opportunity cost, knowledge risk, scalability constraints, and employee frustration that contributes to turnover).
What a Purpose-Built Approach Actually Looks Like
The alternative to one-size-fits-all is not bespoke software -- custom-built systems are expensive, difficult to maintain, and create their own set of problems. The alternative is a platform designed from the start to be configurable for different operator types.
The difference between customisation and configuration is important:
Customisation means changing the software itself -- writing new code, modifying existing features, creating one-off solutions. It is expensive, slow, and creates maintenance headaches. Every custom modification must be supported, updated, and tested with every new release.
Configuration means the software is designed with enough flexibility to model different operational realities without changing the code. A ferry operator configures the system to understand lane metres and tonnage. A tour operator configures it to track equipment and guide ratios. A cruise operator configures it to combine cabins, dining, and excursions. Same platform, different configuration, no custom code.
This is the approach modern platforms like JetSetGo are taking. The concept of "PATs" (People and Things) provides a flexible framework where operators define what they are actually selling -- not in generic terms, but in the specific language of their operation.
For a ferry operator, PATs might include:
Adult Passenger (economy deck, consumes 1 seat)
Adult Passenger (premium lounge, consumes 1 lounge seat)
Standard Vehicle (consumes measured lane metres, limited by height clearance)
Commercial Vehicle (consumes measured lane metres, requires weigh-bridge data, subject to dangerous goods rules)
For a tour operator, PATs might include:
Adult Participant (consumes 1 kayak, counts toward guide ratio)
Child Over 12 (consumes 1 kayak, counts toward guide ratio)
Child Under 12 (shares tandem kayak with parent, counts toward group safety limit)
The system does not need to be rewritten for each operator type. The underlying model is flexible enough to accommodate fundamentally different business structures through configuration.
Inventory tracks extend this principle. Instead of a single capacity number, operators define tracks that represent their real constraints: lane metres, tonnage, passenger counts, equipment units, guide hours, cabin berths, table covers. Each booking consumes capacity across the relevant tracks based on its specific PAT configuration. The system calculates true availability in real time, across all constraints simultaneously.
Pricing engines built for this level of complexity can handle the commercial models that operators actually use. Per-metre vehicle pricing. Season and day-of-week matrices. Channel-specific rate cards. Group discounts that span multiple PAT types. Bundle pricing for cruise packages. The pricing engine matches the commercial model, rather than forcing the commercial model to match a simplified pricing engine.
Does Your Platform Speak Your Language? A Self-Assessment
Here is a framework for evaluating whether your current platform genuinely fits your operation. Score yourself honestly on each question using a scale of 1 (not at all) to 5 (completely).
Capacity Accuracy
Does your system model all the constraints that limit your actual capacity? (Not simplified versions -- all of them.)
Can the system calculate true availability in real time based on the specific mix of bookings already made?
When you tell the system you are "full," is that actually true -- or are there capacity combinations it cannot see?
Commercial Fit
Can your pricing engine implement every pricing structure your commercial team has designed, without workarounds?
Does the system handle the specific booking types your customers need -- vehicles, equipment, cabins, add-ons, dietary requirements -- natively, not as notes or custom fields?
Can you create product bundles, packages, and multi-component bookings that reflect how your customers actually buy?
Operational Integration
Do your check-in, manifest, and departure management workflows use the same data as your booking system, without re-entry?
Can your operations team see, in real time, the state of every departure -- who is booked, who has checked in, what capacity remains?
When something goes wrong (cancellation, overbooking, weather disruption), does the system help you manage the situation, or does it become another problem?
Reporting and Visibility
Can you report on the metrics that actually drive your business decisions -- not generic analytics, but operationally specific data like revenue per lane metre, guide utilisation, or channel contribution by product type?
Scoring:
40-50: Your platform fits your operation well. Focus on optimising rather than replacing.
25-39: There are significant gaps. Quantify the cost of workarounds and evaluate alternatives.
10-24: Your platform is fundamentally mismatched to your operation. The workaround tax is likely substantial.
The Competitive Dimension
There is a competitive argument for purpose-built technology that goes beyond operational efficiency. In markets where multiple operators compete for the same customers, the quality of the booking experience -- online and in person -- becomes a differentiator.
An operator whose booking flow captures the right information first time, displays relevant options (seat selection, equipment choices, add-on experiences), and confirms instantly creates a fundamentally different customer experience than one whose booking flow is generic, requires follow-up calls, and cannot display the options that make the experience special.
According to research from Google and Phocuswright on the travel booking experience, 94 percent of leisure travellers switch between devices during the booking process, and 53 percent will abandon a travel booking if the mobile experience is poor. For transport and tourism operators, this means the booking flow is not just an operational tool -- it is a sales tool. And a sales tool that cannot present your product accurately is a sales tool that is losing you customers.
An operator who can offer vehicle deck visualisation, cabin selection with deck plans, equipment choice with photos and descriptions, and integrated package building has a meaningful advantage over a competitor whose booking flow asks customers to type their vehicle length into a free-text field and call the office to arrange a cabin upgrade.
The Path Forward: Configuration Over Compromise
The transport and tourism industry does not need more generic platforms. It does not need bespoke software, either. What it needs are platforms built on architectures flexible enough to model the real complexity of different operator types -- without requiring custom development for each one.
This is what the next generation of booking platforms is designed to deliver. Platforms like JetSetGo are built on the principle that every operator type has legitimate, specific needs that deserve first-class support in the technology they use. A ferry should be modelled as a ferry, with all the complexity that entails. A tour should be modelled as a tour. A cruise should be modelled as a cruise.
The underlying technology is shared -- one platform, one codebase, one development team. But the configuration layer is deep enough to accommodate fundamental differences in how each operator type works. This is the "one platform, infinite configurations" approach: meeting each operator where they are, rather than forcing them to meet the software where it is.
For operators evaluating their current technology, the first step is honest assessment. Use the self-assessment framework above. Quantify your workaround costs. Calculate the revenue impact of capacity modelling limitations. Measure the customer experience gap between what your booking flow offers and what your customers actually need.
The answers will tell you whether your current platform speaks your language -- or whether you have been translating for so long that you have forgotten what fluency sounds like.
Moving Beyond "Good Enough"
The transport and tourism industry is entering a period of significant technological change. Operators who have accepted "good enough" technology -- because nothing better was available, or because the switching costs seemed too high -- are starting to see alternatives emerge that genuinely understand their operations.
This is not about technology for technology's sake. It is about tools that eliminate the workaround tax, capture the revenue that generic systems leave on the table, deliver the booking experience that customers increasingly expect, and provide the operational visibility that drives better commercial decisions.
Different operator types have fundamentally different needs. The technology should respect that difference, not paper over it with a generic interface and a collection of workarounds.
Your ferry is not a hotel room. Your tour is not an airline seat. Your cruise is not a conference booking. And the platform you use to run your business should know the difference.
Want to map the specific requirements for your operator type? Download the Operator Type Requirements Matrix -- a detailed comparison of what different booking systems should actually do for ferries, tours, coaches, and cruises.