NB: This is a guest article by Steve Evans, a consultant to travel companies looking to get online or improve their web presence.
Not sure what this says about me, but one morning last weekend I woke up early thinking about complexity.
I blame this on a couple of recent online travel consultancy jobs I've completed and also on my experiences with travel companies I've worked for in the past who were either undergoing a change of reservation system or building their own back-end and packaging systems.
Selling travel online is just about as complex as it gets.
However, such complexity doesn't need to be displayed to your users or customers and, in fact, you should do everything you can to avoid that.
So complexity has become a bit of a bug-bear of mine in that there's a few things about complexity in online travel (particularly in back-end systems) and the resulting user experience that customers see that really bug me.
So I had a bit of a rant on Twitter about it (which followers won't be too surprised about).
A couple of people asked me to explain my thoughts in a bit more detail, so here's the series of Tweets with an explanation beneath each.
First point to ponder:
Now this is a real issue affecting many travel companies. They get sold a reservation system which has far too many features and too much complex functionality for their needs and then struggle to implement it and end up having to support it for years.
I've seen this really impact companies bottom-line and I've seen reservation implementation projects that have taken seven or more years (to move from an old res system to a new one).
Not only can it be a tough migration, cost them a lot of money, mean they require more specialist staff, but in many cases the travel company ends up using just a fraction of what the system can offer them.
The usual excuse will be that 'we'll grow with/into the new reservation system' and yes that can happen, but generally it doesn't and parts of it become redundant.
Simple reservation systems do exist! The amount of tour operators and small tour providers who are adopting or looking into really complex dynamic packaging systems is crazy right now.
So many of them just don't need something so complex and company-changing. So, the moral is; make sure you really do need all that fancy functionality before you commit to what can be years of pain.
...next:
This one's a given. The more complex the system the harder it is to adopt it fully.
Switching from one reservation system to another is like open heart surgery for a travel company. It needs the most highly skilled and experienced project managers and the business has to be ready for the changes that are coming.
It impacts almost every department and is one of the biggest change projects a travel company can undertake.
So, make sure you really need the 'all singing, all dancing' reservation system as the change is likely to cost you money unless it's very well-managed (it needn't cost you anything at all if the project is well scoped, managed and implemented).
...and then:
And so we move to the online travel angle of all this complexity.
In my experience, the easier your website is for your customers to use the more money you will make.
Of course, there are a lot of other factors that go into making money in online travel (product, marketing, technology, people, process etc), but the user experience (UX) of your website, and particularly the booking process or flow, is key to your financial success.
Some asked why this Tweet was in this series, the reason is that so many online travel companies over complicate their website front-end purely because they have a super complex back-end reservation system...
...what about:
Which leads nicely onto the next Tweet. Just because you have a million-and-one features in your reservation system doesn't mean your customers want to see/use them all.
Just because your internal staff love using the mega-advanced search feature in your reservation system doesn't mean your users will. Expose just what is necessary to give your visitors a great, simple user experience and make it easy to find product, price it up, compare it and book it - that's all your users want.
There are of course some reservation systems on the market which make it very difficult to hide complexity and some have an all or nothing approach to the front end via templates or an API.
Just don't buy one of these, there's no excuse for this and when exposing reservation system booking functionality onto the user interface you should be able to expose just as much features as you feel your customers want/need (but please test what they might want/need!).
What next?
And so I finished off with a few simple lessons to bear in mind when you're in the business of selecting or implementing a travel reservation system which will be exposed on your website.
...the first tip:
This is important, repeat five times a day if you're in the middle of an online travel web project involving a reservation tool.
...the second:
I can't and won't name ones to avoid (it's not my place). The lesson here is to make sure you use a robust process to choosing a travel reservation system and ensure you get the right people in the room to quiz the potential suppliers.
It's not difficult to weed out the one's that are overly complex or inflexible!
...final one:
Let this be your mantra.
Other things worth noting. Involve a user experience or usability expert/agency as early in the project or selection process as you can.
I find it can help to show the reservation system supplier mock-ups of the UX you want to be able to support so they can see how flexible you need the system to be.
Make sure the API is fully flexible and you can let your customers book their travel and holidays the way they want to, not the way the reservation system dictates.
Let me know your thoughts, I know there's a lot of travel folk with strong opinions on these issues!
NB: This is a guest article by Steve Evans, a consultant to travel companies looking to get online or improve their web presence. Follow on Twitter.
NB2:Wake up angry image via Shutterstock.