Skip to content

Why is our booking engine so slow?

31 January, 2010

During the last few months Hurtigruten has rolled out new online booking engines to allow customer to book travel directly on the Hurtigruten websites in the UKNorway and through our global website. In addition we have launched a solution designed specifically to improve our service towards travel agencies.

The booking engines work, but we have several challenges that need to be addressed. Our challenges can be divided into usability, peformance and feature issues.

Currently our biggest challenge is the speed of the solutions and feature issues in the travel agent solutions. This blog post is under development, so feel free to add comments and ask questions.

Acknowledge the problem: The booking engines are slow

Good explanations for slow software will always exist. That’s not the point. Instead of focusing on the explanations, we must acknowledge the problem and start focusing on diagnosing and solving the problem. Last week I spoke with 10 customers. All of them perceived the Hurtigruten booking engine to be slow. Here’s a quote from one disatisfied customer in Tromsø:

“When I select departure port, the system makes me wait, when I select a date, I have to wait. When I finally click “Find price and order”, the system makes me wait before  I’m told that there’s no departure!”

To further demonstrate the speed issue, I recorded two videos of the actual booking process:

Based on customer feedback and video demonstrations, there is no doubt that the we need to improve the performance. The next step is to understand the commercial urgency of our challenges.

Understand the urgency: We’re losing money every day

Research shows that 41 percent of online shoppers will only tolerate one or two bad online experiences before abandoning a retailer’s Web site. This means that by making our customers wait we’re losing money every day! We’re not sure exactly how much money we’re losing, but it’s probably not 85 million Norwegian kroner (article in Norwegian).

To put this more into perspective, we can look at the online sales funnel for an unspecified period of Hurtigruten’s B2C booking engine in Norway. The illustration below is a simplified version of the online sales funnel, but the data supports the fact that we’re losing alot of customers in our booking process. Some of the leakage is natural. Some people will always use the booking engine to check prices and departure times with no intention of buying. However, based on the research and my previous experience with booking engines, it’s reasonable to assume that improvements in the booking engine speed (or perceived speed) will increase the number of online bookings. If we fix the problem today, we stop losing money tomorrow. If we wait 3 months, we lose money every day for 3 months.

Diagnose the problems

A booking solution consists of several components that affect the performance of the solution. In order to diagnose the performance, we must analyze each component in search of improvement potential. I am not an expert in these areas, but I’m hoping that this blog post will help us get an overview and understand the sense of urgency. Here’s a starting point…(feel free to add relevant information)

1. Front-end code audit

This involves getting a programmer to review the front-end code and come with suggestions that can improve the actual speed and/or the perceived speed of the solution. When people accomplish what they set out to do on a site, they perceive that site to be fastSmall adjustments to the code can lead to major improvements in the user experience.

The programmer should preferably be someone outside the project since programmers tend to become code-blind after working with the same code over a longer period of time. Some issues may be code issues while others may be interaction design issues.  In our solution some improvements are obvious.
The search box on the front page contains logic that slows down the application. Other obvious improvements exist in the transition between steps in the process. When a user clicks “continue”, some waiting time is acceptable, but if large delays exist, the system must provide the user with reasonable feedback. Several techniques can be used to improve the speed of an application.

2. Application review and pay off code debt

This involves reviewing the application code and the connections between systems and identify improvement areas and implement them very quickly. Sseveral different applications work together to present the online booking engine. Each of these applications are continuously being developed.
Each time one application is upgraded with new features, subsequent applications must be upgraded, tested and launched. Over time inefficiencies develop. Every once in a while it’s critical to take a step to the side and look for improvement areas in the application. In 37 signals terms, this is called paying off your code debts.
To put this into layman terms:  When a restaurant changes their menu, expands their opening hours or moves to another location, it has consequenses for other parts of the organization. The owner must print new menus, update their website, change their yellow pages listings, hire new staff, update their reservation system and much more. What seems to be a small change, can have far reaching consequenses. In the short run they resort to quick fixes to ensure that the restaurant continues to operate . As time passes by, new routines and processes develop.

3. Caching methods

Caching is many times the most important instrument went it comes to speeding up a solution. Some of the slowness is caused by unstable/slow connection with Polar Global. By using caching techniques we can reduce the effect of slow data transfer. Data can and should be cached on several levels to improve performance.

4. Server tune-up / Hardware upgrade

This involves investing in more and better servers. The booking engine application resides on a server. Based on the system load, I don’t think too much traffic is our major problem(I might be wrong).

Prioritize and fix the problems – quickly

Once the problems have been diagnosed, we must prioritize the implementation based the complexity and the overall value of improvements. Some improvements are quick and cheap to implement, others may require further analysis and detailed planning.


8 Comments leave one →
  1. Knotilla permalink
    1 February, 2010 15:20

    Judging from the videos I’d focus on 3 areas:

    * Serverside
    * Serverside
    * Serverside

    You could throw lots and lots of money and effort into ajaxifying and trying to cloak your bad performance, but this is so apallingly slow that you’ll never succeed. It will however make some consultant suits very happy. Besides – fixing up the serverside would fix other clients as well, not just the webclient.

    Adding hardware should be for scaling, which probably isn’t the problem as you seem to agree to. Webclients exist (for Hurtigruten) that does this much, much faster (of course by talking efficiently to Hubro). This being making the actual reservation. The normal page flow is acceptable, but when talking to PG it seems dead. I think the web guys did their job just fine. The problem is an uneccesary complex architecture at the backend. Not so much that any link necessarily doesn’t perform, but there’s too many layers and systems. Lots of timeconsuming system-to-system talks. And that needs to be adressed for the well-being of all clients. More bang for each buck spent.

    I know you should never tell anyone I told you so, but I will anyway: “I told you so”. Over and over.

    Caching your way out of this might work, but leads to complicated (buggy) code, and bad performance after the inevitable reboots. The first rule of optimization is after all: “Don’t do it”.

    This app is new so I don’t buy into the code debt argument for this particular app, but in general it’s a valid point.

    Maybe it will all work just fine and dandy out if you kill off Hubro and lift all of it into PG. And maybe everthing grinds to a painful halt.

    Whatever you try, the very best of luck and all that 🙂 And, yes, I do mean that.

    Feel free to delete this comment.


    • Knotilla permalink
      1 February, 2010 16:36

      Uhm, after a testrun I must change my opinion. The client side is also way to slow. The wait-overlay constantly appears and stays in wait-mode for much too long.

      Functionalitywise you’re onto something at least. Some screens are doing too much and feel clunky, but the calculator seems to work at least. That’s an improvement.

      A 9-step wizard? Really? I truly believe that is the worst paradigm to go with, and any sensible creature will get annoyed. Even if it has pictures. Big red buttons for what you want the user to do is also a little scary. You’re already using friendly green letters somewhere else.

  2. 1 February, 2010 18:49

    @knotilla thanks for useful feedback.

    We just have to fix one thing at a time. Research shows that customers are happy if they are able to accomplish the task they set out to do even if the system is slow.

    If we take care of the slowness in the front-end code and aim to solve som of the server issues down the road, we’re at least moving in the right direction.

    As for the 9-step wizard. It started out with a very short 2-step wizard for the simple port-to-port trips. Somehow it grew and became an 9-step wizard. The progress diagram actually lies a bit, since we’ve tried to remove unecessary steps again.

    The work continues. If you take a run through of other cruise booking solutions, you’ll see that several of the other players have more issues than we do.

    It would add to the discussion if you signed with your real name:)

  3. Knotilla aka Ketil permalink
    2 February, 2010 17:01

    Well I guess that would depend on both definitions of “happy” and “slow”. There are limits. And it also depends on the users. Besides your problem statement says otherwise already doesn’t it? For me it would depend on how much time I would expect listening to muzak on the phone. For Hurtigruten I would have picked up my phone, but now of course – things may be slow there as well. But that’s an entirely different discussion.

    You should work on the speed on changing dates and ports and such very small things. Making me (me=the user) wait and disable the entire app as you do gets annoying real fast. I would stop there on the weblayer if I could. Because, you cannot get acceptable performance without doing something serverside. Now I don’t know exactly what’s causing it, but your architecture on the backside is not exactly responsive. If you have trouble connecting as well, well… The error in your screen recording might very well be a timeout… As it is you should have some animations to distract the user, but that’s not a long term solution. “I don’t want to look at dancing bears, I just want to change the date”, screamed the user.

    As for nine steps, you could very well have nine distinct screens. But there’s no reason why everybody should be forced through all of them. What you need to accomplish this technically is:
    1) One page with ports/dates – basically figure out what sailing
    2) Find available products for that sailing
    3) Add paxes
    4) Add anything optional (cars, extras, hotels what have u) and have those pages optional.
    5) Enter pax names
    6) Payment
    7) Ticket/confirmation

    Now 1&2 you could ajax together in one page. 3 is best done alone – when ordering it is nice to add names here, but when checking prices it’s NOT.

    Payment and nameadding could easily be the same screen.

    That leaves ticket which ends the whole circus.

    Now you have a distance/product page, a pax page, payment name page and ticket. That is exactly 3 nexts for me to deal with.

    Hurtigruten has had two systems that works like this so it can be done. And I firmly believe that was a good user interface model. Basically once you set the distance and product you’re free to add “products” to that. A menu. At first only pax is enabled. Once you have pax you could just skip right ahead to payment and namecalling. It is not hard to understand (we had serverlogs to back that up), it’s not that hard to do, and it makes for a killer port-to-port tool. If you think I think wizards are a bad pattern for this, you’re exactly right.

    If it somehow just grew from a cute two-page solution into a nine-step monstrosity – well, that sounds an awful lot like feature creep – or just missing the target by a relatively large margin. From the user’s point of view one could argue you’ve got a 450% increase in complexity and time-to-finish.

    And I did spy on others as well. I’m not sure I agree with your conclusion, but some are worse, I’ll grant you that. But that’s not an excuse really.

    As you gather, my point of view is making the easy stuff very easy to accomplish. The complex expensive trips is probably booked by phone anyway by a *very* wide margin. The killer feature for you online-end-user booking are us the people that live alonge these here coasts. Once that works, try to push your complex package deals to the chinese. Those objectives are further apart than most people give them credit for – and most booking solutions Hurtigruten has tried.

    Now you might conclude that I only think the two solutions I designed are the only ones worthwhile pursuing. And you would clearly be on to something. But then again, I was paid to do it the best way I knew how, and I spent my moderate brainpower trying to accomplish just that. I have yet to see a paradigm that beats it in terms of usability. So I might be hard to convince otherwise, but I (for one) thought really hard and long about this. In the end we actually came up with something novel that worked – in itself interesting. We didn’t just go “Oh, everybody else is doing long tedious wizards, so we’ll do just that now matter how clunky it feels”. And I might even turn down a better solution to cater to my own self-esteem, but that doesn’t mean I don’t have a point (or two, or three…)

    Furthermore I don’t think my real name adds or detracts from the discussion, but now you have it anyway 🙂 Besides you’re posting with an alias as well, even though you have a picture. Robert will recognize me if you don’t by now 🙂 (You might not since I don’t think we’ve met)

    And, when my feedback is no longer useful just say so 😛

    • Knotilla aka Ketil permalink
      2 February, 2010 17:03

      And I bother to comment at all since you seem to go about this fairly sensibly. We might disagree on details or reasons though.

  4. 29 May, 2017 20:11

    There’s definately a great deal to know about this issue. I love all of the points you’ve made.

  5. G.J. Monahan permalink
    20 July, 2017 11:54

    I googled “hurtigruten website problems” and found this page. Evidently this has been a problem for 7 years and it is still not solved?! I have been trying for 25 minutes to buy a simple one-way ticket between 2 Norwegian ports and I can’t do it. I am giving up and buying a plane ticket instead 😛


  1. Solid utvikling i online booking for Hurtigruten –

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: