Several years ago, MIOsoft experienced one of my favorite customer information management disasters. A major computer hardware vendor mistakenly had an address for an office MIOsoft hadn’t used in over a decade as our ship-to address for an order of servers. Although it was corrected in time, this address subsequently popped up in interactions with the vendor for the next several years.
At some point, everyone working with that vendor from MIOsoft had the same question: can the address ever be changed? But it seemed that no matter what we or the vendor did, the address refused to die.
I wish I had remembered a book from my childhood, titled I want to be a computer operator. I rediscovered it recently in a long-neglected box inadvertently turned into a time capsule.
“Can the computer change my address? We are moving soon,” said Lisa.
“Yes it can. Please give me your mailing label. Mrs. Kelly will make a new card with your new address. Then we will 'feed’ this card into the computer,” said Mr. Walters.
In the book, Lisa’s dad is moving, and she needs her address changed for her magazine subscription. Through this process she is introduced to the world of computers: you know, big boxes with spinning wheels, punch card slots, and rat’s nests of wires.“That looks like spaghetti,” cried Lisa.
Written for children over 40 years ago, this book makes the crazy claim that a giant calculator can track little Lisa’s customer information, even when it changes.If I had remembered Mr. Walters’s words of wisdom, I definitely would have suggested forwarding them to the vendor.
Around the same time as the almost-incorrectly-shipped servers, I went to a hospital for a scheduled procedure. When I checked in, they asked me to verify the phone number they had on file for emergencies. It was a number I didn’t recognize.
It turned out to be the number for my long-deceased grandparents, apparently given at some point when I was an infant. Decades later, it had somehow bubbled to the top of my medical record.
Problems like this are common and can cause consumers intense frustration, or even brand hatred. Especially because most of the time consumers can’t understand why they are so hard to fix.
I have heard “it’s not rocket science” in reference to the seeming simplicity of these types of problems from the perspective of the consumer. Considering the computer engineering prowess that was unleashed in the U.S. space program, that statement is actually perfect.
NASA’s use of computers, after all, pushed the limits of computer engineering and helped reinforce the computer age. The Apollo 11 program pioneered the first embedded computers and led to the creation of IMS, widely considered the first database management system.
And yet more than 46 years after Apollo 11, a cell phone carrier can still have billing problems so prolonged and severe that they lose 71,000 customers before the problems can be resolved.
U.S. Cellular’s inability to calculate correct billing and its failure to find tempting incentives to keep customers from leaving weren’t failures of rocket science, they were failures of customer context.
Customer context is the idea that you should have as much relevant information about a customer as possible, so you can intelligently make decisions about how to serve, sell, or market to them as an individual.
It’s hardly a new concept.
Businesses have known for a while that responding faster with better customer information can mean outperforming competition, gaining market share, and avoiding extinction. For instance, sending Lisa an automatic phone coupon to tempt her to visit the nearby ice cream shop just after she finishes a calorie-burning run might be a highly successful customer-context-based marketing initiative.
Proactive customer engagement is an exciting use of customer context, and it’s the one that gets discussed the most often. But if the above anecdotes show anything, it’s that we should stop pretending customer context for reactive customer engagement is a problem every business has solved.
Since Lisa’s life-changing experience was first brought to the general public, a lot has changed in the typical business application that attempts to create customer context in some form.
Highly customized data processing and storage applications from the early years of business computing gave way to broader business application suites that were quickly written in COBOL and accessed shared “Data Bases”. Wide use of databases paved the way for single, source-of-record storage of customer information. The applications that relied the most on the idea of a single customer database were software for Customer Relationship Management (CRM).
Later, the decade of Siebel and Oracle in the late ‘90s and early ’00s suggested that, from the perspective of both the CRM and database markets, the problem of managing and using customer context had been solved.
The icing on the cake for CRM was at the turn of the millennium, when IBM chose and implemented a single CRM vendor from its call centers up. They replaced over 900 individual CRM applications with the largest Siebel installation in the world.
And there we had it. The final nail in the coffin. Little Lisa, who probably did grow up to be a computer operator, could now call IBM and be confident that they would have all the information they needed about her to suggest relevant RedBooks and they could even update her mailing address.
It seemed the customer context problem had been solved.
But, as the opening anecdotes suggest, the continued lack of correct customer context still shows through: many businesses are unable to even reactively interact with a customer.
Additionally, new data sources from social media and new ways of thinking about this data (for instance: social network graphs) push existing technologies to their limits. Apparently most traditional CRM systems just don’t know, or only recently found out, what a Twitter is.
So with the force of the undead clawing their way to the surface, the customer context problem has started showing signs of life again.
Without speculating on all the reasons, the CRM market has clearly been shaken. Siebel’s CRM technology now belongs to Oracle, while Salesforce, the economical alternative to high-priced, on-premise installations, has emerged as a CRM frontrunner. In 2012, IBM ditched Siebel for open-source SugarCRM.
And for the first time since the ‘90s, there’s serious enterprise market interest in non-relational database technology. Customer context projects have leveraged the shifting database and data management markets and begun resuming movement with the animation of a fully resurrected, although still zombie-like, corpse.
My favorite example of a recent customer context project is the MetLife case study from MongoDB. The revolution? Pooling together information and showing it unsynthesized from one web interface, instead of requiring agents to log in to lots of legacy applications and terminals.
At least they will be able to confirm for Lisa that she has a policy, although changing the coverage might be slightly more difficult.
MetLife’s data dump project exposes a peril of traditional CRM solutions: they focused more on the features than the data. Although many claims about CRM solutions made them sound like they provided the full customer context experience, they really just addressed a subset of customer-related marketing, sales, or support functionality.
As such, traditional CRM left the world with simple data quality and integration problems to fix. And we should fix them. But they’re the low-hanging fruit of customer context.
Customer context should be holistic to be fruitful, and it should be thought of as needing a superset of existing technologies that are in distinct markets. Because customer context cuts through the IT landscape and intersects not just with CRM, but with other systems verticals like billing, and with technology verticals like transaction processing, data quality, and data integration.
Implementing customer context requires a different strategy than just picking a new CRM system or database does: you can’t just replace a single Lego piece in the enterprise architecture structure.
True customer context requires synthesis of data into information at the speed of human interaction.
And that data is spread across the business. The data is coming from new places. The data is coming fast, and in many forms, but the computers available are also fast. Complex algorithms, like machine-learning clustering, can be used on data in real time as it arrives, helping to discover the customer out of the noise, and bubbling the correct contextual information to the top of mounds of data.
And so with the dawning of the age of connected devices, providing customer context has more potential than ever.
Which is good news for Lisa, because she’s probably sick of companies not being able to figure out information she’s already told them directly. And she secretly loves ice cream.
If you are working on or interested in customer context, I urge you to read Josh’s post.
And if you have fun or frustrating stories about being on the business or consumer side of customer context failures, share them in the comments or on Twitter.
For Data Migration