Switch Your Booking Engine

What this playbook covers

Switching booking engines is one of the highest-stakes decisions a travel agency makes. Get it wrong and you disrupt every desk in the office for weeks. Get it right and you unlock better fares, faster issuance, and the infrastructure to grow your sub-agent network without adding headcount.

This guide is written for agency principals and ops leads who already know their business and want a structured way to evaluate options — not a vendor brochure.

1. Evaluating supplier coverage

A booking engine is only as good as the fares it can access. Before comparing platforms, audit your current fare sources: which GDS do you rely on (Amadeus, Sabre, Galileo), which LCCs you connect to via direct APIs (IndiGo, SpiceJet, Akasa, Air Arabia, Flydubai), and which consolidator deals you're running through TBO or TripJack.

A modern engine should support GDS, NDC, and LCC natively in a single search — not bolted together via separate portals. Ask each vendor to demonstrate a live multi-source search result where you can see which supplier won each fare. If they can't show you that, the integration isn't production-grade.

Key questions to ask:

• How many airline connections are live in production (not pilots)?
• Can I add a new supplier in <4 weeks without custom dev?
• How do you handle fare discrepancies between GDS and NDC for the same flight?
• Is NDC seat selection and ancillary booking in the same workflow as GDS?

2. Wallet-safe booking: what it means and why it matters

In traditional platforms, a failed booking attempt can still deduct from your supplier wallet — leaving you to chase refunds manually. Wallet-safe architecture means the engine never charges your wallet unless a confirmed PNR is returned.

This requires the booking engine to hold the debit atomically with the supplier confirmation — not issue it on the API call that initiates booking. During a migration, ask for a technical walkthrough of the booking commit sequence: at what exact point does the wallet debit fire, and what happens if the airline API returns an error after the debit?

A system that can't answer this question with a precise "the debit fires only after PNR confirmation" is a financial risk at scale. For agencies doing 500+ bookings/month, even a 0.5% phantom-debit rate adds up fast.

3. Sub-agent markup and commission controls

If you run a network of sub-agents or B2B desks, the booking engine needs to handle markup at the right layer — not bolted on in a spreadsheet after the fact. Look for:

• Per-agent, per-route, and per-supplier markup rules
• Hierarchy support: your markup + sub-agent markup without double-charging the customer
• Commission passthrough from GDS/NDC without manual reconciliation
• Real-time P&L visibility per sub-agent, not a monthly export

A common trap: platforms that look good for a single-desk agency but break down when you add 20 sub-agents because the markup engine wasn't designed with hierarchy in mind. Test with a three-level scenario (master agent → sub-agent → customer) before committing.

4. GST invoicing without the spreadsheets

For agencies in India, GST compliance is non-negotiable. Every booking needs a tax-compliant invoice with correct IGST, CGST, and SGST treatment depending on the state of supply. Manually generating these from a spreadsheet at 500 bookings/month is a full-time job.

What good looks like: the engine generates a GST invoice automatically at the moment of booking confirmation, with the correct SAC code, tax breakdown, and your GSTIN pre-filled. The invoices should be downloadable by the customer and exportable for your CA in bulk. Check whether the engine handles B2B invoicing (with customer GSTIN) separately from B2C — they have different compliance requirements.

5. How to migrate in 2–4 weeks

Most migrations fail because agencies try to run both systems in parallel indefinitely. The cleanest approach is a phased cutover:

1. Week 1 — Parallel testing: Run 10–20 bookings on the new engine for routes you know well. Compare fares, seat selection, and PNR output against your existing system. This is your confidence gate, not a production migration.
2. Week 2 — Supplier alignment: Confirm your GDS PCC/API credentials, NDC certification status, and LCC credentials are ported. Most of this is configuration, not development, if the vendor's onboarding is mature.
3. Week 3 — Team training + cutover route: Train your top-volume desk first. Pick two or three high-volume domestic routes (e.g., DEL–BOM, BLR–DEL) as your first live segment. Hold international until week 4.
4. Week 4 — Full cutover: Kill the old system login for new bookings. Keep read-only access for existing PNR management until those bookings travel.

The most common delay is supplier credential porting. Start that conversation with your GDS account manager on day one — not week three.

6. Questions to ask every vendor

• Can you show me a live booking (not a demo environment) on my routes?
• What is your SLA for PNR confirmation after wallet debit?
• How do you handle a failed confirmation after debit? What's the refund timeline?
• Do you have a dedicated support contact for production booking failures?
• What does your uptime SLA look like during peak Indian travel seasons (Oct–Jan)?
• Can I see your GDS/NDC/LCC connection list with live-vs-pilot status?
• How is refund automation handled — manual, semi-automated, or fully automated?