GDS, NDC and low-cost servicing in one desktop instead of three
Shopping across GDS, NDC and low-cost carriers is now common. Servicing them is not: GDS bookings are changed in the GDS, NDC orders in the airline’s or aggregator’s tools, and low-cost bookings on the airline website. An agent handling a disruption or a refund jumps between three places with three different rules. This page explains why servicing is harder than shopping and what a single desktop changes.
01What goes wrong
The symptoms show up whenever a booking needs to change.
Three screens, three logins
Agents move between the GDS, an NDC tool and airline websites to service one traveller.
Slow changes and refunds
Each source has a different procedure, so changes wait for the agent who knows it.
Missed notifications
Changes for NDC and low-cost bookings arrive outside the GDS queues the team watches.
Training burden
New agents must learn three servicing workflows before they can be trusted with disruptions.
See where it breaks — and how it is fixed
The problem. The agent services GDS tickets in the GDS, NDC orders in another tool and low-cost bookings on airline websites — and changes outside the GDS queue are missed.
The fix. One servicing desktop holds every booking, changes from every source reach one queue, and the integrated GDS terminal is there for cryptic commands.
Explore each problem
Three screens, three logins
Why it happensEach source has its own tool, bought when that content arrived.
How the platform fixes itGDS, NDC and low-cost bookings are held and serviced in one desktop.
Slow changes and refunds
Why it happensEvery source follows a different procedure, so changes wait for the agent who knows it.
How the platform fixes itVoid, refund and reissue are run from the booking; refunds are tracked across sources.
Missed notifications
Why it happensNDC and low-cost changes arrive outside the GDS queue the team watches.
How the platform fixes itChanges from every source land in one schedule-change queue.
Training burden
Why it happensNew agents learn three servicing workflows before handling disruptions.
How the platform fixes itOne workflow for every source, with the integrated GDS terminal kept for experts.
02Why it matters
For operations
- Slower disruption handling and refunds
- Knowledge concentrated in a few agents
- Mistakes when a GDS habit is applied to an NDC order
For the business
- Servicing cost rises with every new content source
- Complaints when a change is missed on a non-GDS booking
For the traveller
- Different service levels depending on how the ticket was issued
- Longer waits for changes on NDC and low-cost bookings
03Why it happens
-
Search is easy to normalise; changes are not
Results can be mapped into one list. Servicing cannot: a GDS ticket is exchanged or refunded with ticketing commands against the PNR; an NDC order is changed through order-management messages; many low-cost bookings can only be managed on the carrier’s own systems.
-
Each source handles disruptions differently
Schedule changes, voids and refunds each follow a different procedure per source, so the same disruption needs three workflows.
-
Tools were bought per source
Agencies added an NDC tool when NDC content arrived, and used airline websites for low-cost carriers. Nobody designed the three to work together.
How servicing differs by content source
The same request is carried out differently depending on where the booking came from. This is how the industry works today; what each airline supports varies.
| Servicing action | GDS booking | NDC order | Low-cost carrier booking |
|---|---|---|---|
| Record of the booking | PNR and e-ticket | Airline order | Airline booking reference |
| Schedule change arrives as | Queue message on the PNR | Order change notification | Airline notification or booking update |
| Void | Ticketing command, usually same day | Depends on the airline’s implementation | Usually not applicable; cancellation rules apply |
| Refund | Refund against the e-ticket, settled via BSP / ARC | Order cancellation and refund messages | Through the carrier’s own process |
| Exchange / reissue | Reissue with fare recalculation | Order change, where the airline supports it | Change through the carrier, subject to its fees |
| Ancillaries | EMDs where the airline files them | Offered and sold as part of the order | Sold by the carrier, often at booking only |
NDC servicing depends on each airline’s implementation of the standard, so the set of supported changes differs by carrier. A good servicing desktop shows what each airline supports instead of presenting every channel as identical.
04Our approach
Normalise the booking record, not just the search result, and service everything from it.
One booking record per trip
GDS, NDC and low-cost segments are held on one record with their source-specific details.
One change queue
Changes from every source land in the same schedule-change queue.
Servicing actions from the record
Void, refund and reissue are run from the booking, with the right protocol for the source.
Cryptic access kept
Experienced agents keep a cryptic terminal inside the workflow for the cases where commands are faster.
05How the Innovate Solution platform solves it
| Problem | Platform capability |
|---|---|
| One view of every booking | Unified GDS, NDC and low-cost search and booking — see the unified flight search case study. |
| Cryptic access when needed | An integrated GDS terminal inside the booking workflow for Amadeus, Sabre and Travelport. |
| Changes from every source | One schedule-change queue — see flight disruption management. |
| Void, refund, reissue | One-click void, refund and reissue for GDS bookings; refund tracking across sources. |
| Ticketing across several GDS | Dynamic multi-GDS ticketing routed by airline. |
How it runs, step by step
- Booking madeGDS, NDC or low-cost — the booking is created on one record.
- Change arrivesThe change lands in the schedule-change queue regardless of source.
- Agent servicesThe agent acts from the booking; the platform uses the right protocol for the source.
- Traveller updatedThe itinerary and ticket are updated and the traveller is notified.
Servicing support varies by airline under NDC: what can be changed, and how, depends on the carrier’s implementation. The platform exposes what each airline supports rather than promising uniform servicing. Background: GDS vs NDC.
06What changes
| Before | With the platform |
|---|---|
| Three tools for GDS, NDC and low-cost servicing | One desktop for all three |
| Changes on non-GDS bookings missed | All changes in one queue |
| Refunds handled differently per source | Refunds tracked across sources |
| New agents trained on three workflows | One workflow, with cryptic access for experts |
See it on your own bookings. A live walkthrough of this workflow on the platform — not slides.
Book a demoWho this is for
- Agencies selling GDS, NDC and low-cost content
- Airline consolidators
- Travel management companies
- OTAs with multi-source air content
Questions to ask any vendor
- Are GDS, NDC and low-cost bookings serviced from the same screen?
- Do changes from NDC and low-cost bookings reach the same queue as GDS changes?
- Which NDC servicing operations are supported per airline?
- Is there still a cryptic terminal for experienced agents?
Frequently asked questions
What is NDC servicing?
Changing, cancelling or refunding an airline booking made through NDC, using the airline’s order-management messages rather than GDS ticketing commands.
Why do agents need one servicing desktop?
Because a disruption or refund otherwise means different screens and rules for GDS, NDC and low-cost bookings, which slows response and causes missed changes.
Can agents use cryptic commands while servicing a booking?
Yes. The integrated terminal gives full cryptic-command access inside the booking workflow for Amadeus, Sabre and Travelport.
Is NDC servicing the same for every airline?
No. Each airline’s NDC implementation supports a different set of servicing operations. The platform exposes what each carrier supports; agents should expect differences.
Related pages
Sources and further reading
- New Distribution Capability (NDC) — IATA
- NDC Standard — developer resources — IATA
- Billing and Settlement Plan (BSP) — IATA
About this page. The problem described here comes up repeatedly in public traveller and travel-agent forum discussions that our team reviewed in November 2026. Examples are paraphrased; no person, airline or booking site is named, and we do not claim how often it occurs. See all travel software problems and solutions.
Next step
See GDS, NDC and low-cost bookings serviced from one desktop.
