Best Buy Customer’s Data Scramble: Even If It’s Not A Breach, Think About The CRM
Written by Frank HayesNothing destroys customer confidence—or E-tailer confidence in a CRM database—quite like this: A New York Best Buy customer logged into his account to discover that the “ship to” address and phone number were changed to someone in Texas. Had his account been hacked? No, a Best Buy customer service rep told him; it was just a database glitch that caused data to be swapped around among customers. Yeah, that’s comforting. But the explanations didn’t end there.
When the customer called Best Buy corporate communications for an explanation, he got yet another story: It was all due to a system test that the customer himself asked for in 2009, when he had trouble ordering a laptop for home delivery. Except that this customer never ordered anything from Best Buy for home delivery. Now he’s left wondering whether Best Buy was hacked, the E-tailer just didn’t bother to warn customers about a database glitch that swapped around account information, or someone really did talk customer service into changing his account information while ordering a laptop in 2009.
The story, at the HD Guru blog, should be even more unnerving to E-Commerce executives than to Best Buy customers. After all, something in Best Buy’s database and logs probably does indicate that this customer bought a laptop in 2009. Or maybe it was the guy in Texas whose information was intermingled with this customer’s.
If the data was scrambled by a glitch in 2009, there’s no easy way for an IT shop to know what happened when. Short of a full-scale (and expensive) forensic investigation, all anyone has to work with is the database and the logs.
If the data was scrambled by a more recent glitch, and that’s how the 2009 laptop purchase by the guy in Texas was associated with the New York customer, it means the glitch hasn’t been cleaned up. And an unknown amount of CRM data is wrong—which makes it worse than useless.
If it was all due to an intrusion or internal sabotage that was covered up in the logs, that’s even more worrisome; it means scrambled CRM data, irritated customers and someone who might return to cause problems again.
It’s easy to dismiss this type of customer complaint, especially when it shows up in isolation. Customers often misremember, they occasionally lie, and they too frequently share account information. Unless there are lots of similar problems reported, we may never hear about incidents like this. They’re all just treated as customer-service issues. Losing the confidence of an E-Commerce customer here or there? That happens. It’s a lot less expensive than tearing into a possibly apocryphal problem in a production database.
But even if you’re not worried about customer confidence, ask yourself: How much confidence would you have in a CRM database you know is wrong?