Misconceptions about the NDC

THERE seems to be a
misconception that there
are fewer facilities available
through an NDC or direct
connection. The view
seems to be that these
connections are merely
built to supply and confirm
inventory but that agents
are stuck when it comes to
things like seat allocations,
any extras like meal
preferences, special needs,
or making modifications.
The truth is that most
of the NDC connections
have facilities for these
things. It’s merely up to
the booking tool provider
to build them. For example,
the FlySafair API allows
agents to make bookings;
modify flights/dates/pax
names; allocate seats; sell
ancillaries; allocate specialneeds
services and check
in passengers.
It’s up to those connecting
to this API to build the
facilities to do what they
want. So your functionality
wish list should be
something to have at hand
when looking for a booking
tool if you are a TMC.
At its essence NDC is
about creating a standard
way for airlines to connect
their central reservation
systems to external booking
tools.
The problem at the
moment is that not all
systems speak the same
language and the idea is to
create a standard.
These connections are
often referred to as APIs,
which is IT jargon for a link
between two systems.
For example, imagine
that your booking tool is
asking two airlines for
pricing and availability for
a flight. One system might
require the booking tool to
request availability in the
following order: departure
date and destination,
whereas the other airline’s
system might require that
availability is requested
in the order of origin;
destination then departure
date. The whole idea behind
NDC is that all systems
format their requirements
in the same way so that
booking systems (GDS and
alternatives) can all easily
plug in without having to
re-format every request for
each airline.
This is the second in a
three-part series on the
NDC. In my next piece, I
am going to look at the
opportunities NDC presents.
Kirby Gordon, head of
sales and distribution at
FlySafair.