Why Location Is a Growing Issue for CRM Systems
As people get more mobile, even transitory, there are new twists to the question, 'Where on earth is the customer?' Unfortunately, CRM systems aren't always equipped to provide an easy answer.
Thu, July 26, 2012
CIO — CRM systems have always held addresses for the contacts and companies you're selling to. Sure, each vendor handles addresses in its own way—and vendors will have endless arguments about how its approach is better—but that's the layer of the problem that doesn't really matter.
Vendors and consultants have lots of workarounds to make that part of the playing field fairly level. In a similar way, there are proven address normalization and cleansing tools and services that can get the street address and town in good shape, at least for North American addresses.
Let's go deeper, though, by looking into some unsolved location problems that span all the systems that CRM users interact with.
ISO Codes: Identifying Countries Two Letters at a Time
Humans like entering country information in their own way—be it Estados Unidos, Etats-Unis or United States—so a classic remedy on data entry forms is to present the list of relevant countries to users as a pick-list. While this eliminates misspellings, the pick-list of all possible countries is too long for any screen.
There are lots of sneaky ways to adjust the country pick-list dynamically so the user isn't presented with an overwhelming scroll. Those same coding tricks can be used to localize to the user's language, but they can be quite the spaghetti-fest of code. A better approach is a manual-entry field that does type-ahead or other techniques that offer the user a dynamically shortened list of the most likely countries for the auto complete.
So far, so good, as we can have country and province names that are well-behaved. But that's not what you really want, particularly in a multinational sales, marketing and channel operation. What would be best is to store countries and provinces as the International Standards Organization's two-character codes. That'll be what rules, workflows, filters and Boolean statements like best: totally regular codes invulnerable to misspelling or word-order errors.
Of course, this works only for the systems that you control. What about the enterprise systems you don't control, including the other data sources that push data into the CRM tables? You guessed it: You need a data filter layer, either as part of your integration server or as a cyclical process that runs through the CRM records to ensure address conformance. This needs to be table-driven, with lookups for all the permutations of error patterns you discover, such as that marketing automation system that insists upon calling South Korea "Korea, Republic Of."