Adventures in airline optimisation
It may come as a great shock to some of my reading audience, but air travel—meaning not just the planes, but the complete service—has not yet been perfected. I found in a recent experience that there is certainly room for improvement, especially with respect to human-centric service management.
Let me tell you a true story to illustrate what I mean. I set out a couple of weeks ago to fly from the UK to Australia—a complex journey involving several legs, beginning on a Sunday morning and ending on Monday evening. I should tell you up front that in the end, I got to my destination less than 2 hours behind schedule after good flights. So, for me at least, the story ended well enough, although my luggage took an extra 26 hours to catch up with me. But the day taught me some good service lessons.
Things got off to a rough start when I tried to check in online the day before, only to be told by the airline computer system that “one or more members of my party1 are not able to be checked in online.”
Well, despite not being a morning person, at 3:30 a.m. the next day I set out to attend to this in person. At the airport, I discovered a small monitor with departures information. Tucked away in the top corner, it said my flight, originally scheduled for 6:05 a.m., was now scheduled for 11:00 a.m.
It turned out the airline had run into a problem. The plane I was meant to be on had arrived the evening before with a leak of oil from the nose-wheel. This required repair before it could fly, and the repair was not yet completed. But that detail I only found out much later. All I knew at the time was that there were long queues at the desk (a combined bag drop/check-in desk). I joined the queue, and as happens so often with such queues, I waited, while nothing happened, for a very long time.
The airline's perspective
Now, this sort of situation is neither unknown nor unexpected for airlines, so there are predefined processes for the airline to invoke.
First, they flew two engineers from the maintenance team to my airport. The prognosis was for a 5-hour delay while repairs took place.
Obviously, this affected lots of bookings. The airline therefore set out immediately to reroute passengers who had already checked in online, to get them to their destinations with minimum delays. This was done in several ways: by moving bookings onto their own later flights2 or onto other airline’s flights, and even by planning for passengers to go by taxis to alternative airports about 2-3 hours' drive away. Many passengers would also need rescheduling/rerouting of their onward flights from the airline’s main hub airport after delayed arrival there, and that was initiated too.
The process says that passengers arriving at the airport would be notified of the issue as well as the airline's response to it upon reaching the bag drop/check-in desk, and also via telephone/email. Delayed passengers would also receive vouchers for food/drink when they got their rerouting information.
So far, so good. It might seem to a casual observer that the logistics issues caused by the glitchy plane were all being handled capably.
The passengers' perspective
To the passengers, however, it felt a bit different.
Most of us had gotten out of bed at 3 a.m. or thereabouts3. We expected to drop bags, get through security and sit down with coffee. Instead we got to the airport and joined a long and seemingly motionless bag drop/customer service queue. Most had not noticed the small monitor and had no idea there was an issue.
It took over 30 minutes to get to front of that queue, only to be told a reschedule was needed and to be sent over to the ticket desk on the other side of the concourse. That queue took about 2 hours to get through. The only information on what was happening during all this was feedback from fellow passengers, and as you can imagine, we had a few observations and questions:
We’ve been standing up for 3 hours and still don’t know what’s happening. Nobody had spoken to us, except for an airport employee who was friendly but uninformed. (Grumpy and informed might have been more welcome.)
Thanks to the monitor display, most passengers from the 6:05 assumed they were now going on the scheduled 11:10 flight. This ultimately didn't prove to be the case, but was the accepted truth for several hours.
Was the 9 a.m. flight actually full? And if so, were there people on it who would swap with some of us who had more to lose by being delayed, perhaps for a financial inducement that might cost the airline less than rerouting us later?
Why was there no attempt to deal with us as individuals, given that we had individual needs and context? As an example: there was a couple in their 80s booked to fly back to Mongolia. Their son-in-law just wanted someone to understand that they didn't need to go that day, and just wanted to be told they could go back home and have it sorted out the next day—or the next week.
Now, the human psyche (or at least the European version of it) will find some kind of humour in most circumstances, and we found some. For instance, there was a much shorter queue for frequent flier elite members, but this didn’t move at all for ages because one man, on reaching the head of the queue, commandeered the airline phone for over 40 minutes. This left the “elite” guys behind him moving even slower than us mortals.
I tweeted about my disappointment with the service level, and got a response asking me to send them a private message. But none of us knew how to do that.
I eventually got a message saying “Our booking team informs the passengers via call or email in case of any schedule changes.” Well, that was true; the woman behind me had apparently gotten such an email. Her husband called just as we got to the counter (3 hours later) to say he’d seen the email when he was going to bed in Vancouver and “did she need to know?”
Service management lessons
The real purpose of this story is, of course, to pick out some key service management lessons. There were two key ones for me in this situation:
What the airline did, they did very well. What the airline didn't do arose from the fact that the passengers were not really treated as people (let alone a range of individuals with different needs, concerns, and priorities), or at least a range of situations/types.
So here is what I think could have been done to make those passengers more likely to fly with that airline again.
- Get as much relevant information as you can—especially human information.
When people are involved you have to deal with them as people. Of course all the technical stuff has to be done, but as well the people need to be treated as people, and ideally, as individuals. Some might be delighted to be delayed in exchange for compensation; others might absolutely need to get home or to a meeting. For some, even, the whole point of the trip might be destroyed by a delay and they may as well turn round and go home.
At different times over recent years, I have found myself in all three of those categories at different times, so you can’t just capture this once and record it on a person’s data record. Getting such insight would only have required someone to walk along the queue asking some basic questions. This idea of different needs for different people at different times is something that IT or process designers find hard to cope with.
- Use the available information in better ways.
The woman behind me in the queue illustrates this one well: in addition to the email, they had called her landline and left a message. But what was the point in the airline calling a Vancouver phone number to notify her of the delay, given that their IT systems knew she was in the UK, some 7,000 kilometers away, since she had checked in for her original flight the day before?
Another instance4: if the idea is to make arrangements for someone that involve a 2½ hour taxi journey, and they need to leave by 6:00 a.m. to make that newly arranged flight, then go find them and tell them before 6:00 a.m., not when they eventually get to the front of the queue at 7:00 a.m. (Not sure you really need complicated computer systems for that one!)
This could be seen as a minor application of the ideas behind “Big Data”—in this case, aspirations to medium-sized data might have made a difference.
- Triage is always worth it.
Triage as a concept for making the best use of limited resources to deliver maximum value has been with us for at least 3,000 years. In its most brutal and obvious application, on the battlefield, it is about putting people or situations into three pots:
Establishing which passengers fall into which classes, in a scenario such as the airline faced, is critical to creating a truly effective response for those passengers. It quite simply didn't happen. Instead we were dealt with as all-equal records in the system.
(If you want to really succeed in service management, you need to understand that “Business as Usual (BAU)” process-based approaches only work when business is as usual. Rob England’s Standard+Case5 approach has highlighted this well.)
- A human perspective will often suggest opportunities to improve.
If you imagine being a delayed passenger, many refinements to the airline's process will occur to you. To someone in that situation, for instance, heaven might be a complimentary tray of tea/coffee/juice and maybe a seat or two. This isn’t rocket science, it is empathy, a skill required in effective service management.
One more thought about perception here really illustrates how little things can affect customer perception of how valued they feel. The engineers who fixed the plane flew back on it. It was good to see that degree of faith in their work. But it was just a little galling for those of us 5½ hours delayed, sitting in the back of the plane, to see the airline’s engineers flying business class!
- Expand the scope of your analysis.
I think this is a classic example of how suppliers build emergency processes. Everything done was done well. But not everything was done, and what was not done might have been, if only some human relations specialists6 had been involved. That might mean someone getting telephoned at 2 a.m. and told they are on duty—but it would make quite a difference.
And planning of these things needs to be done by people who have experienced these things. Both airlines and ordinary IT departments have access to a vast group of people who have experienced the good and the bad of service and are uniquely placed to help improve it. I know that I would be delighted to work with this airline to create a more holistic approach to the way they handle delay and rerouting management.
The other thing that this story illustrates to me—and a very pertinent ITSM issue it is—is the importance of having service improvement as your focus rather than process improvement. The latter will only make you better at what you already do—but if you need to do new things, it won’t help. In fact, it will most likely increase your costs without improving your service.
So, in summary, let me reiterate a simple thing about my experience. In the end I got there on time—albeit via a very different route on different airlines. But I felt that I had been treated—at the beginning at least—like a record in a file rather than a person. And it is the person in me, not the technician, that will choose whether or not I fly with that particular airline again.
¹In retrospect, this was my first little warning about (not) joined-up IT systems here—the airline’s computer system knew I was a party of one, not too much human-oriented thought required to just say “you” rather than all that silly “one of your party” stuff.
2Scheduled later, but now leaving earlier than the broken plane. We presume these filled up early in the process and mostly with premium level frequent flyers.
3As I may have mentioned already, I am NOT a morning person! Three a.m. took real effort; I was tempted to treat it as merely staying up late the night before—glad in retrospect I didn’t try that.
4Actually the same poor woman, I do hope she got home eventually.
5This could stand more exploration and I hope to write an article on this topic very soon, but you can find out more about it from Rob himself here: http://www.youtube.com/watch?v=D0bbjkT1ImQ (Link resides outside of ibm.com).
6In this context, this merely means someone who can actually communicate with people in potentially stressful situations.
After 23 years working for the UK government, moving from forestry to IT Service Management via prisons, stores and training, Ivor now works for IBM’s Tivoli organization helping customers understand and improve their Service Management. Ivor was an ITIL author (versions 1, 2 and 3), part of the panel that wrote BS15000 (fast-tracked to ISO/IEC 20000), an ITIL trainer and examiner since 1991 and active in itSMF since 1995, having spoken for them in 34 countries.
Unified Device Management
IBM Endpoint Manager lowers the total cost of managing and securing mobile devices, laptops, desktops, and servers – physical or virtual, on or off-network, personally or corporate-owned.
Log Analysis Simplified
IBM SmartCloud Analytics - Log Analysis provides the capability to rapidly analyze unstructured data to assist in problem identification, isolation and repair.