The Challenge
TGI Tours USA, a mid-market travel company operating from Florida with a focus on Caribbean, Latin American, and domestic US travel packages, had reached the limits of what their incumbent platform could deliver. The business was running on a white-label booking engine licensed from a regional technology vendor — a system that provided basic flight and hotel search functionality but offered no path to custom supplier integrations, no API access for automation, and a checkout flow that converted at 1.1% against an industry benchmark of 3.5–4% for comparable travel products.
The fundamental constraint was architectural: the white-label platform was a closed system. TGI Tours could not connect their own preferred hotel suppliers — with whom they had negotiated net rate agreements representing 8–12% better margins than the platform's default Hotelbeds and GTA connections. They could not implement a loyalty programme without the platform vendor's involvement and an additional licensing tier. And they had no ability to deploy the AI itinerary builder that TGI's product team had identified as a key differentiator in their competitive market segment.
The business case for a custom platform was straightforward: at TGI's transaction volumes, the difference between a 1.1% conversion rate and a 4% conversion rate represented approximately $1.8M in additional annual revenue. The white-label platform's licensing cost was $180K annually for a system that was actively constraining the business.
A more complex challenge was the GDS architecture decision. TGI Tours served both corporate travel buyers — who predominantly book on Sabre, the dominant GDS for US corporate accounts — and leisure travellers booking independently. A single-GDS implementation would have required TGI to either exclude one segment or pay expensive cross-selling fees to route Sabre content through an Amadeus integration. SpYsR's recommendation, accepted after a 3-week technical discovery, was to implement a dual-GDS architecture capable of routing flight queries to either Amadeus or Sabre based on passenger profile, origin airport, and carrier preference — a technically demanding but commercially essential decision.
Our Approach
The 9-month engagement began with a 5-week discovery and supplier integration mapping phase. SpYsR's travel technology architects worked with TGI's product and commercial teams to catalogue all 12 supplier relationships the company held: 2 GDS connections (Amadeus NDC + Sabre Web Services), 4 hotel bed banks (Hotelbeds, GTA, IATI, TGI's proprietary net rate inventory), 3 car rental APIs (Avis, Hertz, Budget via TSD Global), and 3 activity/experience suppliers. Each supplier API was assessed for response time characteristics, error rate profiles, rate structure complexity, and authentication requirements. This assessment directly shaped the architecture decisions that followed.
The platform was designed as a set of independent service domains: a GDS routing layer handling flight search and booking, a hotel aggregation layer combining all bed bank sources, a car rental layer, a checkout and payments layer, and an AI recommendations layer. Each domain was independently deployable on AWS ECS, communicating via an internal API gateway. This service boundary design was chosen specifically to allow GDS-specific issues — Amadeus or Sabre outages being a known operational risk — to be isolated without affecting hotel or car rental availability.
For the B2C frontend, SpYsR selected Next.js 15 with server-side rendering for search result pages. This decision was SEO-driven: TGI's existing white-label platform rendered search results entirely client-side, making them invisible to Google. The new platform's server-rendered flight and hotel search pages were designed to be indexable, with canonical URLs for popular route/destination combinations forming the basis of an organic search acquisition strategy.
The payment architecture combined Stripe for credit/debit card processing with a 3DS2-compliant authentication flow, and a custom escrow-style holding account system for group booking deposits — a TGI-specific requirement for their tour group business segment.
What We Built
The dual-GDS routing layer is SpYsR's most architecturally complex implementation in this engagement. The routing service maintains real-time availability queries to both Amadeus NDC and Sabre Web Services, with an intelligent fallback mechanism: if one GDS returns an error or takes longer than 4 seconds to respond, the system automatically routes to the other GDS for that request. The routing logic also applies business rules — Sabre is prioritised for bookings originating with TGI's corporate accounts (identified by authenticated session), while Amadeus is prioritised for leisure search. In practice, the system serves approximately 60% of queries via Amadeus and 40% via Sabre, with the split varying by season and product type.
The hotel aggregation engine deduplicates and normalises hotel inventory across all four bed bank sources in real time. The deduplication challenge — where the same hotel property may appear in all four sources at different prices, with varying cancellation policies and content quality — is handled by a property matching algorithm using a combination of hotel chain codes, geographic coordinates, and property name fuzzy matching. The algorithm achieves a 97.3% deduplication accuracy, validated against a manually curated test set of 500 properties. Where the same hotel appears from multiple sources, the cheapest available rate is surfaced by default, with source alternatives accessible one click deeper.
The AI itinerary builder allows users to input a destination, duration, and travel style (budget, comfort, luxury, adventure), and receive a suggested day-by-day itinerary with pre-populated hotel and activity recommendations. The AI layer uses OpenAI's GPT-4o API for itinerary narrative generation, with TGI's product catalogue fed into the context as structured supplier data. The itinerary builder outputs are bookable directly — each hotel and activity in the suggested itinerary is linked to a live availability check, allowing users to proceed from AI suggestion to confirmed booking without re-entering search criteria. In the first 6 months of operation, 22% of AI itinerary sessions resulted in a booking — a 4.8x conversion premium over standard search-and-book sessions.
Automated booking management replaced a significant portion of TGI's customer support volume. The platform sends structured post-booking communications — confirmation, payment receipt, supplier reference numbers, pre-departure checklist, and digital travel documents — automatically via a Postmark email pipeline triggered by booking state machine events. The support ticket reduction of 58% was driven primarily by the elimination of "where is my confirmation?" and "what are my booking references?" queries, which had represented 63% of TGI's support volume on the previous platform.
The Impact
The platform processed $2.4M in transactions in its first 12 months of operation — against a pre-launch business case projection of $1.9M. The 26% outperformance against projection was attributed by TGI's leadership primarily to the AI itinerary builder, which was not in the original scope but was added during the build phase and proved to be a significant acquisition driver.
Platform booking conversion rate averaged 4.2% over the first year — against the industry benchmark of 3.5–4% for comparable product mix, and a 3.8x improvement on the 1.1% rate achieved on the previous white-label platform. The conversion improvement is multi-causal: faster search performance (median hotel search response time 1.4 seconds vs 6.8 seconds on the previous platform), the dual-GDS architecture providing better flight availability and pricing, and a checkout flow that reduced the number of steps to confirmation from 7 to 3.
Twelve supplier integrations are live and operational — all catalogued in the initial discovery phase — making TGI one of the more deeply integrated travel commerce platforms at their company scale. The architecture is designed to add new suppliers within a 2–3 week integration cycle without changes to the core booking flow.
TGI's customer support team processes 58% fewer tickets per unit of booking volume than on the previous platform, with the reduction concentrated in information and documentation queries. The team has been redeployed toward complex booking modifications and group travel servicing — higher-value work that the automation cannot replace.