Even with a modern booking platform, part of an agency's daily work is still done in native GDS commands. Innovate Solution puts a GDS terminal inside the admin, alongside the booking, so staff reach the command line faster and without leaving the screen they are working in.
The problem
A booking platform handles the common path well: search, book, ticket. But the long tail of agency work still happens in native GDS commands — looking at how a booking has changed, checking a fare display, working a queue, adding a request the standard screens do not cover.
Without a terminal in the platform, that work means leaving it. The agent switches to the GDS's own application, signs in there, retrieves the booking again by its locator, does the work, then comes back and brings the booking record up to date.
Each switch costs time, and the switch is where mistakes get in: the wrong booking retrieved, a change made in one place and not reflected in the other, a customer kept on hold while two applications are lined up side by side.
Why it is hard to fix
Experienced agents think in commands
Replacing every command with a button is slower for the people who are fastest. The commands have to stay.
Context is lost between applications
The booking the agent was looking at has to be found again on the other side.
Two sign-ins mean two sets of access to manage
Every extra application is another thing to provision, secure and support.
What we built
The admin has a GDS terminal built in. It sits with the booking, so an agent goes from the booking record to the command line without changing application — and back again the same way.
Agents keep the native commands they already know; what changes is how quickly they get to them. The platform already holds the agency's GDS connection, so there is no separate application to open and sign in to before work can start.
How it works
-
Open the booking in the admin
The agent starts where they already are — the booking record.
-
Open the terminal
The GDS terminal is available from the admin, alongside the booking.
-
Work in native commands
Commands are entered and responses come back in the terminal, as they would in the GDS itself.
-
Carry on in the booking
No switching back, no second application to close.
What changes for the team
| Before | With this in place |
|---|---|
| Two applications open: the booking platform and the GDS | One — the terminal lives in the admin |
| A separate sign-in before any command can be run | The terminal is reached from the admin the agent is already signed in to |
| The booking is retrieved a second time on the GDS side | The terminal is reached from the booking itself |
| Command-line skill is useful only outside the platform | The same commands, used where the booking is |
What it does not do
- It is a terminal, not GDS training. The commands are the GDS's own and agents need to know them.
- It runs on your GDS account. What you may do there is governed by your agreement with the GDS.
- We do not claim it replaces every function of a GDS's own desktop product; it removes the need to leave the admin for the work done alongside bookings.
Questions
What is an integrated GDS terminal?
A GDS command-line terminal built into the booking platform's admin, so native GDS commands can be run alongside a booking without opening a separate GDS application.
Do agents have to learn new commands?
No. The terminal takes the GDS's native commands, so experienced agents use what they already know.
Who benefits most?
Ticketing, support and operations staff who regularly need the command line for work the standard booking screens do not cover.
Related
About this page. This is a solution case study: it describes a problem and how the platform solves it. It contains no customer names and no performance figures. For measured results from a named customer, see the customer case studies.
Want to see this working on your own bookings?
