Where's My Flight?
A couple of months ago, I had an experience as a member of a user group for which I have often designed: harried business travelers. The frustrating cross-channel communication I had with an airline taught me several lessons and reinforced some of the themes I heard at SpeechTEK 2011.
I was waiting on an interminable security line at O'Hare, wondering if I would make a 5:50 p.m. flight home. I originally booked a seat on this flight, but changed my reservation to a later flight when it seemed I would need more time with my client. Luckily, I left the client's site on time and traffic was light, so I arrived at the airport by 4:30 p.m. Excited by the prospect of being home in my own bed at a reasonable hour, I pulled out my smartphone and opened the airline application to see if I could change my reservation back to the earlier flight while I waited on the security line.
To my dismay, I couldn't find the earlier flight on the airline app, and it was not listed as a possible alternate flight. Yet, I knew the flight wasn't canceled because it was listed on the airport's departures screens. I was puzzled. The application had won me over a few months earlier by always supplying exactly the information I needed, exactly when I needed it. Now, however, my beloved app was failing so profoundly that it pushed me to try other channels. I tried logging onto the mobile Web site, a somewhat painful experience, but I could not change my flight. Thus, I was forced to break down and actually call the airline, which demonstrated lesson number one in this cautionary tale: When one communication channel fails to meet the needs of a customer, he will try another channel. I'm sure that the airline would have preferred to meet my needs in the much-less-costly mobile channel rather than using valuable time with a call center representative.
Note that I was not happy about calling in this case, even though I like and often choose the phone channel to contact an airline. The difference here was my environment; standing on the security line and managing my luggage in a loud and crowded place made a phone call cumbersome. I had chosen the most convenient communication channel but had to switch because I couldn't complete my task. So I started the call annoyed at having to use a difficult channel.
This brings us to lesson number two: Forcing customers to switch channels is risky, because they chose the original channel for a reason. A corollary to lesson two is that we should also be cautious when labeling customers as "mobile users" or "IVR users," as if these were immutable, mutually exclusive categories. My experience demonstrated a claim I've often made: Many customers select communication channels opportunistically, according to what fits the situation best.
After I finally realized why my earlier flight had disappeared from the mobile application, I learned another lesson. It turns out that the earlier flight was fully booked, so to show me only timely, relevant content, the application didn't show flights for which there was no availability. In many cases, that would have been the right decision, but for my particular circumstance, it was exactly the wrong choice and caused confusion and an unnecessary call to an agent. The lesson here is that you can overly constrain the information you present to customers.
At first glance, it seems silly to take up space on a tiny mobile phone screen listing flights with no availability, but there are lots of business travelers who find themselves in exactly the situation I was in. If a customer is shopping for flights, it would make sense to hide flights that are full. But when you know the customer is considering changing flights, she might want to know about any flight that has not departed. For this use case, it makes sense to display overbooked flights and let the customer decide if she wants to sit at the gate and try to fly standby.
The other reason the application should have showed the earlier flight is that my original ticket was for that flight. It was confusing not to see the earlier flight displayed because I had direct personal experience with that flight. Thus, the final lesson is that context does not just mean what's happening right now, but it also refers to the customer's situation. The application should have known that I had originally been on the earlier flight and showed it to me, even if it was fully booked.
The solution is simple: If the mobile application had listed the earlier flight but marked it as booked, I would have had the information I needed to make a decision and would not have needed further contact with the airline. A fuller understanding of the use cases and context of use of the mobile app, and self-service systems in general, could have prevented this loyalty-shaking experience. Hardly specific to mobile applications, this lesson applies to all of us trying to build effective customer self-service applications.
Susan Hura, Ph.D., is principal and founder of SpeechUsability, a VUI design consulting firm. She can be reached at susan@speechusability.com.