Ten factors to define a Global Distribution System [GDS]NewsBy Alex Bainbridge | December 14, 2009Share This article was originally published on Recently we have seen a spate of travel startups describing themselves as a GDS - Global Distribution System.I am intrigued by TourAbout, a social GDS. Then there is Kumutu, an adventure and activity tour GDS.So are they really a GDS? And what is a GDS anyway? Is this just semantics or are the legacy (they won't like that) GDSs being taken on by new entrants?Lets have a go to define what a GDS is. Perhaps this is an impossible task, like defining pornography, where the US Supreme court said it was tricky to define but you know it when you see it.One thing for sure, a retail travel website with an affiliate programme is not a GDS. Agreed?OK - onto the 10 checkpoints No content editing - if the supplier puts in a really bad description of their product it is down to them to fix. The central GDS does not edit the content.End point contracts - the travel agent commercially contracts with the hotel chain / airline / tour supplier. The GDS doesn't even need to know the detail of that contract, they are just the data conduit. (This contrasts to where, for some web systems, the supplier contracts with the website company, the affiliate / agent contracts with the website company - hence they are centralised contracts)Purpose of the GDS is to communicate live product, dates, price & availability data - this can lead to a transaction (booking) via the GDS or something else (e.g. a PPC click, if the company is a media model company). Many traditional GDS systems revolve around the objective being a transaction rather than marketing but I digress.GDS is commercially agnostic - they shouldn't care which products are returned first to a product search query. If a search order is required (it will be) then it should be fair and equal to all suppliers based on some form of random order :)Able to apply own business logic to front end - if an agent / media company wants to use a GDS as a source of products to run a media model they can. Or an agent can run a transactional model. The GDS shouldn't care what kind of front end model is being applied (again, the traditional GDS model is based on transactions, but that has to change at some time)Open to all to take part - tricky one - but say a hotel chain wants to join a GDS and a similar hotel chain is already on there. There should be no objections to the new hotel chain joining. In this sense a GDS is a true aggregator not a curator of product.Trusted intermediary - the GDS acts as the central, trusted, tracking mechanism for all bookings between supplier and agent. The GDS acts neither for one or the other.Global - the same product can be represented in multiple languages sharing the same prices / availability. If not global it is just a DS right?GDS charges based on the technology burden not on the value of the transaction - doesn't matter where the decimal point is on a piece of data. Tend to charge based on how much traffic / load placed on system.Able to use GDS for own channel pricing - say a supplier wants to give a specific price to a particular agent. The GDS should permit end point to end point specific price contracts. Remember the GDS is just the data conduit.... Did I miss any out?