When Slow Data is Bad Data

by David Plotkin

In my new job, I travel quite a bit, often on short notice. This has the unfortunate side-effect of frequently leaving me sitting in a center seat, squashed between two people who should eat less and exercise more. So, when the opportunity arose during check-in to purchase an aisle seat in “Economy Plus”, I jumped at the chance to have a more comfortable 6 hour trip.

Everything went fine at first. I was presented with a seat map which showed my existing seat and the empty ones. I picked the seat I wanted, provided my credit card information, and pressed “Enter”. Within a heartbeat, my email showed that I had received a receipt for the purchase. Apparently United’s accounting systems were really fast, though oddly, the transaction showed as “Continental” on the AMEX statement. Oh well, they did merge recently, so maybe Continental’s accounting system was what they kept, and someone just forgot to change the name. I just hope it doesn’t confuse MY company’s accounting system.

Things started to go south when I returned to the seat map, and discovered that I was still assigned to that center seat. I refreshed the screen, logged off and logged back in again, but it would not show the correct seat assignment. Since the transaction receipt did not actually call out the seat number change, I began to wonder whether I’d actually gotten the seat I’d asked for. Next step: call the United Reservations desk.

Of course, they were experiencing “higher than normal call volume”, so I provided my confirmation “number” (which was all letters that sounded like one another), my last name, verified a few details by saying “yes”, and got dropped into the queue to wait. Not a big deal, I have a speaker phone and just went about my business while that theme song droned on in the background. Just to keep things interesting, the music would stop periodically, giving me the false hope that the call was finally being answered. Nope.

When someone did pick up, it turned out that all that information I had provided to the automated voice system had to be provided again, apparently it too is a silo. I explained my problem, and the reservation agent told me that I was still in that center seat according to his seat map. At this point I started to get a bit upset, so he did some more checking and found that on the reservation (which I couldn’t see online) it did indeed show that I was in the aisle seat I had worked so hard for. He assured me that when I checked in, the correct seat would be on the boarding pass. However, having lost faith in the process, I insisted he stay on the line while I checked in, and sure enough, the seat was correct and all was well with the world.

Those of you who remember my blog “The Saga of the Safeway Sandwich” know that I like to dig into the costs of poor data quality. As I was waiting for the check-in to occur, I asked the agent whether he got a lot of calls from irate customers because the seat map didn’t update. He said that he did, and that some people shout at him about it (I did not, but I thought about it).

There are a whole lot of things going on here, things that are costing the airline money because the seat map doesn’t update when you change seats. Of course, they need more people to staff the phones, not even including the extra time it takes to repeat information which has already been provided. It also can’t be easy to be a reservations agent, and having people shout at you for something that wasn’t your fault doesn’t make it any easier. I will forgo comments on whether it matters that the customer was inconvenienced. It does to some businesses, not to others – and I’ll let it go at that. I’m sure you have your own opinions.

And you know, if the seat map doesn’t update the next time, I’m going to call again, because I’m not a very trusting individual.

Related Posts Plugin for WordPress, Blogger...

David-Plotkin

David Plotkin is an Advisory Consultant for EMC, helping clients implement or mature Data Governance programs in their organizations. He has previously served in the capacity of Manager of Data Governance for the AAA of Northern Ca, Nevada, and Utah; Manager of Data Quality for a large bank; and Data Administration Manager at a drug store chain. He has been working with data modeling, data governance, metadata and data quality for over 20 years. He serves as a subject matter expert on many topics around metadata, data governance, and data quality, and speaks often at industry conferences. 

  3 comments for “When Slow Data is Bad Data

  1. John Biderman
    June 1, 2012 at 5:36 am

    Another great real-world story of customer interaction with data. Keep ‘em coming David.

    This is interesting in that it sort of stretches the boundaries of what we consider “data quality” issues. Usually when we are examining data quality (checking consistency, for example, or number of nulls, or clean addresses) we are not looking through the lens of an application front end but are looking directly into the databases. And we’re looking at data at rest, for the most part — the result of what the applications have wrought. In this experience, the data as such was correct — your seat was reassigned in the system — but the presentation was not; the application apparently had cached the page or the data or both, rather than re-executing its query to fetch the latest update. So, if the application stinks, is it a “data quality” problem in the strict sense, or an application code problem? Similarly, the siloed systems you experienced that don’t appear to pass data between them in any timely fashion expose a data integration problem. These are all data management issues to be sure, and certainly affect the customer experience, but what are the boundaries around what we are talking about when we address “data quality”?

  2. David Plotkin
    June 1, 2012 at 5:11 pm

    Hi John,

    As usual, you raise some interesting and thought-provoking ideas. Let me address them if I can.

    First, I never actually said that this was a “data quality” problem, though I do think of it that way. Was I stretching the definition? Maybe, maybe not. In her book “Executing Data Quality Projects: Ten Steps to Quality Data and Trusted Information” Danette McGilvray seems to very much believe that Presentation Quality is one aspect of Data Quality (see step 3.9). And since arguing with Danette about data quality is kind of like arguing with Moses about the 10 Commandments, I’m pretty convinced.

    But even if that doesn’t convince you, I still maintain that a strong case can be made that this is a data quality problem. Yes, the data in the database is correct, but remember, I COULDN’T TELL that. From the standpoint of the most important person in this transaction (that being ME), the data was incorrect (different from what I entered), and thus of poor quality. As more and more of these self-service applications come online this problem will only get bigger. If you dig into the root cause you are likely to find that the fix is in the application code, but that is often the case with bad data (and badly presented data). Does that fact make it NOT a data quality problem? Let me ask this: if the root cause was that people were entering the wrong information, would that be a “People Management” problem rather than a data quality problem?

    I suppose we could get into an academic argument (oh, wait — what’s your day job?) about the “strict” definition of data quality, but I am not going to do that. For the points stated above, I consider it to be poor data quality, and don’t even think we are stretching the definition. Besides, wasn’t it fun to read, whether you classify this issue as poor data quality or not?

  3. June 8, 2012 at 5:06 pm

    Interesting points, John. I will have to side with David here in that I also think the situation he described is a data quality problem. What was that he said about arguing…? :-)

    The fact is the customer (David) did not have the correct information presented/available to him. It caused him and the company much wasted time (and aggravation). The various root causes doesn’t mean it’s not a data quality problem. That is the beauty of looking at the situation through a data quality lens. We bring together information about the data itself, associated processes, people and organizations, and technology in a way that we might not have looked at them before. We can then see interactions and solutions that we might not have discovered otherwise. I liked the way you (John) quickly moved into problem solving mode and suggested possible root causes. Thanks for getting me thinking on a Friday afternoon!

Leave a Reply

Your email address will not be published. Required fields are marked *

Add video comment