The Vendor Roadmap to SCRM – Part 1

Before we begin, two caveats:

1) When I said I would never write another series I was so sure this would not happen — then, this became too long…

2) Social CRM is not a technology, never will be.  This is the vendor complement to The Roadmap to SCRM series I wrote before — you will need technology to deploy your strategy, this is what vendors should offer you.

Sometime ago I wrote this series of posts called “The Roadmap to SCRM“, five parts (plus an extra one added for lack of clarity) that explained how organizations can build their strategy from CRM to Social CRM.  It is based on years of experience and many deployments of CRM, and it is still applicable (by the emails I get about it).  Warning: It must be adapted to your needs, it is not ready to go as is — same as CRM, there is no one size fits all.

I also talked about what vendors need to do to become SCRM-ready when discussing the recent acquisitions (Attensity acquiring Biz 360 and Lithium buying Scout Labs).  Even better, right before releasing this post (which I wrote last week and was trying to make it a complete post, not a series — before I ran out of time) I noticed that fellow deep-thinker, practitioner, and exceptional CRM-meister Filiberto Selvas wrote a similar post to this (now you get to compare, how about that?) which you should read for more perspective.

I have been mulling this post for some time and I want to talk about what different vendors are doing to deliver Social CRM ( that is the next post on this series).  Let’s get into what vendor-driven SCRM should look like…

The attention on SCRM has not been on the strategy side; it has been on the technology.  This is unfortunate, but not unexpected.  I wrestled with the concept of writing this post, I did not want to cement a notion of “what the technology for SCRM should be” in either vendors; or users’ minds, but I feel we are at a point in the evolution into a market (we don’t yet have a SCRM market, here is why) where it is necessary to do so as the direction is starting to become more clear.

First things first, what does the SCRM stack look like?

Vendors venturing into the SCRM world today come from many areas: some of them provide communities, some of them social analytics, others do — well, not exactly sure what they do, but they call it Social CRM — lots of options out there if you are looking.  Remember, though, that we are not talking about technologies — Social CRM will require changes to people, process, and technology to be implemented — and that is where the stack comes in.

You will need technology to deploy SCRM functions, no questions about it.  However, you will need to do most of the heavy work (remember CRM? customization was the hardest part of the implementation) by leveraging a platform or architecture, and building on top of that.  The stack pictured below is the core platform or architecture you will leverage to deploy Social CRM functions.  Let’s examine it a little closer…

First, let’s talk about the essence of what SCRM will bring to your company: people’s perspectives dressed as actionable insights.  The Social Evolution (of Generation C as Paul Greenberg and Mike Fauscette call it) means that people aggregate into communities.  OK, fine – they were aggregating into communities before, the concept is older than — well, older than sliced bread, for sure.  However, the social evolution brought them to use online communities and store the shared knowledge in electronic form.  This is a major, major difference.  That means we now have access to this data and we can use it.

And use it we will, that is where the second layer comes in: analytics.  We can try to dress it up as a new concept also, call it Socialytics, Social Media Analytics, or something similar — and some of the tools we use are fairly new, to correspond with the newness of the social channels — but the truth is that this is still analytics, same as before, same as in the future.  You can leverage your analytics engine, you can add a social analytics engine, or you can do both (probably what I would recommend in most cases for now).  However you do it, make sure you do it — without actionable insights, the outcome of analysing the information, there is no Social CRM.

I have written some articles on how to leverage analytics better in the Social X world, you can find them here, here, and here.

So, here comes the tricky part — this is the layer-to-be-named-later (feel free to drop some naming suggestions in the comments below).  This is where we actually take action — where the company implements the actionable insights and improves the processes, the products, the services — the experiences.  For lack of a better name right now, I will call it the Actionable Layer Unit (ALU – if you know the acronym, you are as geeky as you think — not fair to use google or wikipedia).  And even worse than the name, there is no software that you can buy to do this — this is all elbow grease basically.  You have to take the actionable insights and make something with it — else, why collect the data and analyze it?

(hint: if you would’ve followed the recommendations I made way early in the roadmap to SCRM for companies, you would already know what to do — the picture below is a reminder and I also talked about it at my Collaborative Enterprise post in TheSocialCustomer)

Finally, the missing piece-de-resistance — the cherry on top of the sundae of sorts.  The integration layer.  Yeah, no more silos, no more standalone solutions, no more — well, whatever you want to call it.  Social CRM must be integrated.  Let’s say you collect the data, and you analyze it, and you decide to take some action on it — what do you with it then? Easy, put it in the system-of-record — the good old CRM (or SCM, or ERP if you are talking Social Business or Collaborative Enterprise) system.  You need some way to integrate the Social CRM platform or architecture to them, some way to send the insights, resulting actions, and data to store with the corporate information.  If we were to leave in an ideal cloud world, that would be simply a question of doing some PaaS to PaaS calls and voila!  We don’t live in that world — so we need connectors, API calls, or whatchamacallits to do the job.

So, what do you think?  Too simple? Will this put the argument of Strategy versus Technology to rest once and for all? Can that argument ever be put to rest?  Would love to hear what you have to say…

(remember, there are other parts to this series, so don’t overexert yourself by commenting on this one only)