When Going Social, Keep Your Eye On the CRM Puzzle

By Kelly Craft (@krcraft) Nov 29, 2011

I've spent a lot of time lately exploring some of the newer Social CRM solutions being developed and frankly, I'm concerned about some of what I've seen in the attempt to swing the innovations for Social too far from the Management part of SCRM. You're probably wondering why you should care if I have an opinion at all, but if you're planning now for product enhancements & integrations later, then voices like mine are important.

I'm your other customer. An internal one that will also help make or break the success of your SCRM solution. Make me your advocate by developing your products so it is easy for us to make you rich and respected for providing quality solutions. We're the front-line knowledge workers who are going to have to make all the pieces of the puzzle fit together to give your customers the complete picture.
(And we'll take the direct hits if those pieces don't fit.)

Social at the Cost of Data?

I'm no Enterprise 2.0 thought leader, but I have been a "techie in the trenches" for the past decade as a Professional Services Implementation "expert" for Enterprise collaboration software, which means I've architected solutions, integrated and migrated to and from most of the top traditional CRM packages that come to mind, not to mention a handful of mid-market ERP packages, gaining a level of data intimacy that many strategists haven't. And I've implemented sales processes that would make your head spin.

All in the pursuit of providing adequate analytics as the outcome so your customers can manage their customer relationships.

What I've observed is that some vendors are so overly-focused on socializing the process with unstructured data/process innovation dreams, that they're too cautious about laying the right groundwork for future scalability based on a true understanding of the smallest data sets required for optimal analytics and further feature growth. I won't presume to offer up a lesson here on 3-layer "constraint, schemata and object" architecture when there are much brighter Knowledge Management development experts out there, but I will share some basic thoughts on structured minimum data sets and why they are still important.

Unstructured vs. Structured Data — A Precarious Balance

Let's illustrate the need for non-structured/structured balance with a recent experience I had while testing new SCRM software. I put it through many different scenarios in an attempt to build a use case that would demo the product end-to-end, but the one function I found most interesting was when I imported a test batch of contacts with a csv file. While I was mapping address fields I noticed in the user interface it looked like I was plunking them all into one address field. My professional services brain went into over drive at that point, asking questions like:

Well this is interesting…I wonder how this works when I search on multiple states to either flag accounts in my territory or run a report on my territory…you know, so I can keep an eye on my pipeline & and commissions?
I wondered if the data was being truly parsed into any sort of coded structure with constraints so that we didn't have multiple dirty data entries for California: Cali, CA, CAL…
What happens in the business logic layer if the user is doing manual account creation and skips the state field altogether? Boy! That will be a lot of fun for the Order Processing department when I push the sale back to them to invoice and ship! WHEE!
Users won't care much if they're using Googlefied-style searches on most screens. While I have a deep respect for the need for more natural human language in developing business intelligence, the potential impact on the product's future ability to integrate with ERP/Accounting packages that rely upon the data in basic address fields like City, State and Country for segmentation that drive things like commission territories is worthy of forethought and a concession to the need for some standards.
I checked in with a respected company that develops web-based VOIP billing solutions and learned that they absolutely do hard-code those fields and only Googlefy the results on screens.
In short, the 'C' in CRM stands for customer, or in the world of data, it still stands for the Customer Record.
There must be respect for and knowledge of the Taxonomy of how the customer handles the sales process once the external social lead becomes a real customer, while still enabling people to enter their own Folksonomy in less critical entry fields.
You don't want a hard-coded relational monster with 236 possible fields for a single record, not counting related tables/fields (been there, done that, haven't we?), but there is a bare minimum of account detail and segmentation that can't be optional if the end goal is full CRM functionality including actionable reports and metrics.
If done right, this is accomplished with as few as 20 well thought-out fields.

It's the "little things" you don't plan for now that will trip you up later when the analysts start vetting your solution.

In another example, I was testing Opportunities created via Twitter leads. I noted that the "Stage" and "Likelihood of Close Percentage" fields were not related in any way.