Earlier, we delved into the details of a booking journey from entering the destination (read part 1 here) to selecting the flight seats (don’t forget to read part two here), sharing the most important takeaways based on our decade’s experience in designing clever digital solutions for our global clients in aviation. But at Mito Digital, we are not landing just yet.

Have you missed our previous articles on booking flows? No worries, catch up with the series here:

Are all booking flows identical in aviation?
How to master your online booking flow in aviation – part 1.
How to master your online booking flow in aviation – part 2.

Summary / Payment page

Ever came by a webshop summary page where everything (including the shipping address and payment details) but the exact items you were about to buy were shown? Still, you were eager to take yet another look to make sure you have the right items? It is crucial that users are explicitly able to press that very final okay button while seeing a total overview of what’s in the basket. They don’t want to end up in Zagreb instead of Zanzibar (no one, really). They need that very final reassurance, and to have it all under control.

On the company side, sure, that means a great many details to handle. And the more passengers there are, the busier it all gets. No wonder we did a lot of experimenting in order to simplify, even compress the page. (A little insight for you: an A/B test for one of our high-flying aviation clients, Wizz Air, showed that using a sidebar led to a better conversion rate among customers. Even though we were all convinced it was an outdated pattern that must be replaced. Yes, that’s how crucial testing with your real users could be.)

And here comes the interactive (and often unpleasant) part for the user. Which is, at the same time, a mission-critical (and more pleasant) factor for your business. The payment. Let’s have a closer look at the possible methods:

• Debit / Credit card – This might come as a surprise, but a lot of people don’t know what a debit card is. Or they stress out about not having a credit card when asked for one (yes, even the naming can be a tricky issue). There are some small but important details that shouldn’t be neglected, such as the 3D Secure protocol (3DS) which is obligatory in Europe.
• Account money (either from refund or loyalty) – It’s not a surprise that airlines prefer to refund in virtual currency rather than actual one. But what could (and shouldn’t) come as a surprise for the customers is that their balance may not be used for all products. And if unused, it expires with time.
• Gift card (because, well, Zanzibar as a birthday present?)
• Wire transfer (if allowed)
• Region specific providers for large enterprises (such as iDEAL in the Benelux, Barion in Hungary, or WeChat Play in China) – If you are large enough to generate significant revenue.
• Or any combination of the above – At least, ideally. But it’s not a piece of cake anymore when it comes to development, so it should be well considered whether it’s worth it.

Providing the opportunity to save debit / credit card information is also a good practice (that is, if you’re the one storing the data, and are able to handle the higher cyber security risk.) We have learned already that most people aren’t really into typing. But, like everything, this solution also has its downsides. The browser might mix the saved card details up – and since they’re hidden behind asterisks, your (already strained) customers won’t even know why their payment failed. So they’ll end up typing. And they’re not really into that.

Success / Itinerary page

Hello and welcome to upsell heaven! Your happy customer has just managed to buy his/her flight ticket to their dream destination (Zanzibar, is it?). Well, or at least to a destination. Now that the stress is off, (s)he might be more willing to pay for extras such as rental car, hotel and other 3rd party services. If there are a lot of these, they can either be shown on a whole separate page, or integrated into the success or confirmation page.

Showcasing all the important details once again, the success page is kind of a summary page nr2. So much so that in the case of PLAY airlines, these two screens are almost identical – well, except for the payment section which is added later. Again, it’s all about reassurance: even though the ticket has already been paid, your passenger might want to check that the flight indeed takes off 2 months later to Zanzibar City, and not 2 days later to  Zagreb.

This page can also be (and sometimes is) the same one as the so-called trip details page. However, we suggest that they be different, with this one being a one-time page where the user can’t return later. In the case of a travel dashboard, however, bookings are accessible and manageable anytime. Besides the itineraries of previous and future trips, there are further features as well, such as passenger information alongside companions, or saved payment methods.

Navigating through the flow

The way users are able to navigate between steps and screens is just as important as the screens themselves. A strong focus should be put on the process of the booking – ideally, nothing should distract the user from that. No amazingly rich inspirational content, not even any access to other supplementary information. In our opinion, even the footer should be minimized both in the sense of content and size: a few pixels high, displaying only those few mandatory links.

As always, there are some backend limitations you will need to take into account. Customers can not simply run back and forth in the flow, modifying the contents of their basket in between steps. And they are definitely not able to go back from the summary page – from that point on, they can only confirm or start it all over.

Also, there are some general details you should pay attention to, even obligatory ones. Your users should be able to exit the booking flow – for instance, by clicking the logo in the top left corner (alongside a confirmation dialog popup.)

And never forget the aspects of accessibility: on the website of the Icelandic PLAY airlines, you can easily navigate through the entire booking flow by only using the keyboard. How cool is that? Don’t worry, we will delve into this crucial topic much deeper in a future article.

Game over and try (fly) again: the session time

As for the session duration, users mostly have a limited amount of time for the booking process. If they run out of it, the process fails as the expiration drops all the data. In some better cases, they can extend the time limit – in worse cases, they can take notice of the fact that it has expired. And in the worst cases, it’s not even communicated: it just shuts down without prior warning or notification, displaying the all-time favorite server error message. Oops, something indeed went wrong.

A session that instantly starts once users arrive at the main page is definitely not a practice we would suggest. Even if they’re only there reading stuff about Zanzibar in order to create a pros and cons list to convince their spouse to travel there, the clock is ticking. And they haven’t even started with the actual booking flow yet. Needless to say that ideally a session timeout should never happen. However, until it leads to a decrease in revenue, there probably won’t be any resources allocated to fix this (for instance, by automatically extending it in the background.)

So passengers had better hurry with that booking if they are to catch their flight. Especially if they want to pay the same price as they started the process with, because, despite all the fuss about the session time, tickets are usually not put on hold. The user can easily end up seeing a different price on the summary page (and it’s almost never a cheaper one), or a notification saying tickets are no longer available.