Silly Twitter, Tweets are for Biz

There is a lot of noise on whether or not Twitter should be used for Business.

On one hand we have examples like ComcastCares, DellOutlet, JetBlue and many others that have been used as case studies.

On the other hand, there is me.  I wrote about not using it, about treating it as an IVR, and even getting rid of Twitter altogether.  I have had reservations about it from the beginning (can you really have a conversation in 140-characters? What happens to loads when you start to escalate all your interactions? How do you measure successfully?  How do service outages affect your delivery? And so many other questions).

Last week, my reservations moved to certainty.

I spent the past six weeks or so attending conferences.  I live-tweet them as a means to both provide a service to my followers who want to know what is going on in real time, as well as electronic note taking.  I put a hashtag to my tweets, and when I need to write a blog post about the event, simply get a transcript for the hashtag (I use WTHashTag, there are other tools) and my post is mostly written.

I was at Dreamforce 2009 this past week live-tweeting the event.  I was not keeping track of how much I was tweeting — but apparently Twitter was.  About an hour or so into my live tweeting I get an error message through my client.  It happens.  Conferences, especially large ones, bring Twitter to its knees and the famed Whale makes more than one breach.  I just go online and put a few tweets online until the volume slows down and I can use TweetDeck again.

This time was different.  Whenever I entered my tweets online and press submit, I would get an error message that said that I had exceeded the Status Update Limit and that I would have to wait several hours to resume.  I tried to look it up online to see what I had done wrong – but could not find any more information on their web site on that specific error.  I know that fellow blogger and friend Marshall Lager had the same problem.

(I found out later on that the Status Update Limit is 1,000 a day — nowhere near where I was.)

I went through frustration, anger, and resignation (cannot remember the other stages of grief — but probably went through all of them – including a “negotiation” to let me send just one more tweet).

Then started thinking. Not being able to live-tweet was detrimental to my business. Twitter is NOT a business tool.

It was not only the limits – but how Twitter handles users having problems:

  1. If this was a serious issue it should be very well documented in a easy-to-find place.  I did not go back to the original terms-of-service — but relying on a TOS as the sole documentation is a bigger failure than to lock me out.
  2. I am assuming that Twitter runs on pretty smart computers.  Could they not figure out that the status updates were all different, had the same hashtag as a lot of other traffic, and maybe – just maybe – look it up against a master calendar of events and hashtags and let it be?
  3. Similarly, could they have potentially sent me a message (oh, I don’t know something short, like 140 characters or less, in electronic form) to warn me?
  4. Once the problem occurs, the online self-service should have the answer — or support should reply rather quickly (this is a perfect example of running support with automation tools – I would have gotten my answer).

I would have been willing to consider using Twitter for business (yes, there are problems but they all have problems).  Alas, If I can be locked out for an arbitrary and undocumented reason – why would I rely on it as a business tool? If service is not where it is supposed to be – should I make a more sensible choice?

I will continue to use Twitter, but I won’t be rely on it for any critical business functions.  I guess it is true, you get what you pay for.

What do you think? Am I being too harsh on them? Another chance?

Why Chatter Matters

Well, as usual I am late to break the news.

Salesforce introduced Chatter with great fanfare — and most everyone covered it in detail and analyzed it (Dion Hinchcliffe, Sameer Patel, and Michael Krigsman provided some of  my favorite coverage).

I am going to tell you what I think most people are missing and the reason it really matters.

Chatter is not Salesforce’s response to the social prowess of Microsoft, Yammer, Sharepoint and friends.  Yes, I know that Marc Benioff said that — but he always goes after Microsoft.  It is also not a leap-frog to get ahead of SAP and Oracle in social functionality.  That would be short-sighted and naive, as either one of them can then do pretty much anything they want  to get ahead in turn.

The key to understanding the value that Chatter brings to the table was evident on the second-day keynote, when we talked about platforms.  Deep within the many amazing demos we saw from customers was the answer of why Chatter matters:

It is part of the platform.

It is not a feature or a function that becomes part of an application, it is part of the basic infrastructure that Force.com provides.

I have been saying from the very beginning that you won’t be able to prove ROI for your investment in a social network if you try to get beyond the initial listening and reacting.  This is one of the main reasons why organizations have not gotten past this point: they are being asked for a return on investment that is not there, cannot be calculated.  You can do some calculations for basic functions you will perform – but there is nothing really that talks to the infrastructure investment.

My answer has always been: you won’t get an ROI, but you need to invest on it as if it was infrastructure.  Who computes an ROI for more storage? or an additional laptop? a printer?  Those are infrastructure components that your organization must have and you just invest in them without expecting a specific return on the investment.

Back to Chatter.  By integrating it into the Force.com platform Salesforce accomplished three things:

  1. It changed the conversation from reacting to social events to making social part of the architecture.  We have advanced from trying to figure what to do to making the people and the applications within the organization become social.  When applications and systems can talk for themselves (as they can with Chatter) the conversation changes.
  2. They have shown that the cloud is indeed in progress, and that they are no longer just a SaaS or on-demand vendor with a cool marketing term.  The cloud is a series of interconnected platforms, and Salesforce has gotten closer to it with this move than ever before.
  3. It has essentially changed the game for all the feature vendors with social tools. No, they won’t put them out of business — to the contrary, they have enhanced their chances for survival (if they are smart).  They no longer have to worry about the underlying architecture and infrastructure of their product, they can ride on the cloud and just focus on the features and improving them.  This is the true meaning of working on the cloud – not worrying about the technology underneath but actually being able to focus on improving the Experience Continuum.

I know there are at least two to three years before we actually see this implemented and see more details (Chatter is not expected until late 2010 to begin with).  I know that it may not happen (yes, I read the Beta Agreement — sorry, Safe Harbor statement that Marc displayed on screen as well as everybody else).  And, yes, I will be disappointed if it does not happen — but even if that is the case, the milk has been spilled.  The path to the cloud has been uncovered.

I have sustained for some time that Salesforce was focusing on the applications too much and not enough on the infrastructure, and I finally got the sense that they are turning that around (of course, they will continue to make applications and sell them).  I see them as a platform provider with some decent to good applications.

Alas, by making the cloud matter they are not merely catching up to their competitors — they may even be leaping ahead… stay tuned!

So, what do YOU think of chatter?  Is it really a revolution in the basic infrastructure? Or an underwhelming set of social tools that are not even up to par with the market?  Please let me know your thoughts…

For more of my thoughts on Social Businesses you should follow me on Twitter here.
And, don’t forget to subscribe to my RSS feed here.
http://www.pretzellogic.org/2009/11/21/chitter-chatter-salesforce-ups-the-enterprise-2-0-ante/

Chattering About Salesforce at Dreamforce

Salesforce has taken two separate paths in their progress towards becoming a established cloud vendor: separating the platform and the application.  Although they are not two separate companies, that begins their path to becoming an enterprise-class provider, allows us to analyze both separately, and marks a milestone: they have finally grown up into a world-class vendor.

This is an analysis of the applications announcements.

To begin, I would like for Salesforce to get rid of the marketing phrase “no software”.  With a reported 188 million lines of code, there is no way that this qualifies as no software.  True, there may be no customization necessary but maintenance of 188 million lines of code qualifies as software for any vendor.

The interesting thing here is what they have done with all that code.

Service Cloud 2.   I saw this demo a few times already including the now (in)famous jaunt at Oracle Open World earlier this year.  The demo plays well, the features are quite in line with what the rest of the market offers, and they really have managed to do a good job, led by Instranet’s former CEO Alex Dayon, to integrate that acquisition and grow it.  While not revolutionary and market-changing, I am glad to say that after 10 years of following them they finally have a competitive entry in this market.  They claim 8,000+ clients for the original service cloud, and even though there are no announced clients yet for Service Cloud 2 there are some implementations underway.

Three things that stuck out the most for me: the knowledge base integration, Salesforce Answers (a model that needs some work but certainly holds promise to draw in community participation across all social networks and partners’ knowledge bases in real time for the best answer), and the integration with Cisco’s unified communications platform (to create  complete customer interaction solution) certainly looks interesting.  It must be noted that even though Cisco’s offer is not the market leading one, it is fairly simple to replace (in theory) with any other.

This release makes them a competitive vendor among a decreasing group of vendors that can solve the problem of traditional multi-channel service solutions.

Sales Cloud 2. This was the major step forward in this announcement.  Pretty much redone both at the interface level as well as features, and made to work more the way salespeople actually work.

I really like items like the scheduler, the storage of files in the cloud, the integration with outlook, but more than anything I think that the new Genius mode (where it finds similar deals to the one being worked on, takes best practices and materials from it, and allows the sales person to leverage that into the new deal) holds the most promise.  I was also really impressed by the new Quoting interface and functionality, I think that it holds a lot of promise (still need to see integration into price books and price lists to declare it a winner).  Finally, the charting and report builder that comes with it (and the so simple to use drag-and-drop interface — clicks, not code is the slogan) is something that must be seen to truly appreciate.  There are other improvements to it, such as mobile interface, social network integration, and – of course – the integration with Chatter (more on that later).  All in all, this is the product that is going to both solidify their presence in the market and holds the most promise. If they can in the next couple of years bring their service cloud to the same level as sales cloud is today it would certainly be impressive.

Chatter.  Chatter is, as Marc Benioff introduced it, a facebook and twitter look-alike solution for enterprise applications.  Dion Hinchcliffe wrote a very good post on this that will give you more information.

This is what the convergence of an enterprise 2.0 and SCRM implementation mixed with a a social network could be.

Deeply integrated with Salesforce’s products, it allows users to subscribe to activity streams for each client in the database.  Activity streams will be one of the most important aspects for the next 2-5 years for organizations to tackle and by introducing Chatter, an activity stream consolidator, Salesforce puts themselves in competition with the likes of Socialtext, Socialcast, Cubetree, Yammer, and other similar solutions for the enterprise.  One big difference: it is already integrated with the business functions for Sales Cloud 2 and Service Cloud 2.  This could prove to be very, very big for them.

My biggest concern: it introduces another social network that will in time need to integrate with partner’s activity streams, and external solutions. While it is an interesting announcement and it puts Salesforce in a different category (for now), it remains to be seen how successful they can be without creating or embracing open standards for inter-enterprise collaboration (which the other tools accomplish through APIs and by not being “married” to any particular vendor).

Bottom Line:  Sales Cloud 2 remains the most solid release among their lineup. Service Cloud 2 is, if it proves to work in real world situations, an interesting addition to the market. Chatter — well, time will tell the wisdom of their ways in this undertaking.

Building Communities as the Saying Goes…

As I wrote in the final part of the Roadmap to SCRM series, we are plunging into an era of community participation.

Communities are so much more than the traditional forum-like model.  It is necessary to build good communities to get value and a return on the investment you put into it.

There are plenty of common wisdom sayings we use in our everyday life to guide and explain our actions.  I have found three popular sayings that apply to community building that can be used as rule of thumb.

In the land of the blind, the one-eyed man is king

I know this will come as a shocker, but there are lots of charlatans and “snake oil salespeople” out there.  People who not only don’t have experience and knowledge but they say with such authority and conviction that you are tempted to believe them. Alas, if you go beyond the soundbite there is no substance, no value.

These are the people that hurt a community the most since they tend to throw themselves into the role of leader or super-users.  I wrote before that communities are self-policed and self-managed, but when the community is too small it is hard to spot and “control” these charlatans.

Avoid if you can these people.  Until we have a reputation system based on more than noise made and buzzword compliance, demand and expect credentials to back up everything said.  Just because anyone can get a twitter account or a blog, does not mean they deserve to be heard.

Provide Sex Education, not Sex Training

This is a deviation from the Chinese-attributed story of teaching a man to fish versus giving them food.  This adaptation was first uttered, that I heard, by Mike Muhney in a webinar I attended – and I think it is a brilliant way to describe what your communities should be about.

Even in support communities you have to ensure that all members learn and grow.  The purpose of being a member of any community is to grow by sharing.  However, the growth should not be tactical (training), but rather methodical (education). Would you prefer that I solve your technical problem today, or that I teach you how to solve them yourself next time?

Good communities are made of people who want to extend their knowledge and both learn as well as impart valuable lessons.

A rolling stone gathers no moss

I wrote in my roadmap to SCRM series that communities are created and dismantled in short term, few of them live to be long-term.  Don’t be afraid to participate in different communities, to expand or contract them as the purpose is served or changes.

Keeping constantly moving is a way to ensure that you learn, grow, and reach new people for the different communities in which you participate.  You benefit yourself and others by cross-pollinating and frequenting different communities, by inviting new members in your communities.

Make sure to take advantage of that.

What are your favorite sayings to describe – well, anything and everything you do?  Are mine off the mark?  What do you use as your rule-of-thumb to build your online presence?

The Roadmap to SCRM – Part 5 of 5

Part 1 – Introduction
Part 2.1 – SCRM-E2.0 Pivot Point
Part 2.2 – SCRM Business Functions
Part 3 – SCRM Rules Layer
Part 4 – SCRM Channels Layer

Alas, the last part of this series (and my favorite) communities.

I do believe that communities are going to become the most important part of any social business – even to the point of quasi replacing the customer as the recipient of products, services, and experiences.  I said this in my first long post on SCRM (A Brief History of SCRM), and I still maintain it.  It is one of the two pillars of my research into 2010 and beyond.  There are three things I want to cover at this high level:

First, why communities and not clients.

A very common assumption from organizations is that communities are nothing more than groups of customers.  I defined communities before as

a like-minded group of individuals that favors two-way communication as a way to increase their power and knowledge

The critical parts of this definition are the increases in power and knowledge, not the aggregation or grouping of individuals.  Individuals will remain as they are, single entities that purchase products, receive services, and interact with the organization.  That is not going to change, nor is the delivery of experiences to customers going to change.

What must change is the way organizations interact with communities.  Until now the collective thought is that communities are “owned” by organizations and that they are entitled to the knowledge and benefits derived from them.  If the organization provides a support community, the knowledge generated by it is now part of the corporate knowledge-base.  If the organization sponsors a marketing community, it can be used a focus group.  Nothing is further from the true.

There is a lot of value to derived from a community, but none of it comes directly from the community (OK, some of it does probably — a support community will reduce the number of support tickets, a marketing community will provide insights into R&D needs, and a sales community does reduce the cost of sales – but the largest value you can obtain is not from “owning” the community).  The major value an organization can derive from a community is that it knows who the influencers for their customers are.  What better value can you obtain from a group that to know who the influencers to your customers are, and have the ability to influence them, change their mind, an even obtain a referral.

This is similar to outfitting your house’s basement with all the amenities so your high school-age son or daughter brings her or his friends over all the time.  What better piece of mind as the parent of a teenager that having them at home – and with their influencers (sorry, friends).  This is the way you should think of the communities: as the points of influence for your customer, and the people you need to interact with so they, in turn, influence your customer in your favor.

Second, purpose of communities in SCRM.

The best implementation for any community, regardless of the purpose is to provide a platform and let the users define and use their own communities.  Let them self-police and regulate their own communities (preserve the right to close communities that are offensive or otherwise detrimental to your business or society but let the community manage their own users), and you will notice a much richer knowledge and participation.

There are three purposes for communities as part of an SCRM strategy:

Ideation and Innovation – generate ideas related to product, services, features, good and bad.  Either use the information provided to innovate and improve existing components or to create new products.  The organization can participate as a member, but ideation communities are better served by letting them freely express ideas and features, acknowledge them, inform on the progress, and provide news and information about other products – not as marketing, rather as informational channel.  The role members play as active two-way participants and co-creators make them very different from focus groups (which are exclusively one-way offline communities).

Service and Support – these are traditionally forums, but are not the only example.  The idea is to have the community members assist each other, and generate knowledge that can be leveraged by the organization to augment their existing knowledge-base.  Participation from the organization as super-users or admins is necessary to maintain the community active and engaged, although heavy recruitment of super-users is an alternative, as the members don’t care where the answer comes from as long as it is correct.  A reputation system is mandatory for trust in the answers to develop.  A very important part of enlisting the community to create content is to ensure they are also there to assist in the maintenance as it changes.

Feedback – we traditionally see these communities develop as subsets of the other two, when people begin to express their opinions about product or service as a result of a service transaction or ideation implementations.  The main role of these communities is to monitor people’s feedback and respond in teal time to problems or situations that arise. Twitter is probably the best known example of how these communities are used today.  The critical aspect is to capture and act on the feedback, then use it internally to improve the underlying processes.

What’s about Sales communities?

Not part of an SCRM implementation; they tend ot be internally focused, collaborative groups that offer the ability for salespeople to collaborate and improve their jobs – but no measurable direct sales benefits to the organization.  For organizations to be able to create and perceive value from sales the current sales model of one-to-one, privileged relationships between sales people and customers must change.  No one in the organization owns the customer, the customer owns the organization.  Alas, I Don’t see that happening anytime soon, but would love to see it.

Third, what types of communities are we talking about?

Sure, when I say communities you immediately think of the traditional model of forums – but there is so much more than that to consider.  Yes, forums are one part of communities — but not the best or more important one.  They serve a specific purpose and they do have a place in your community sub-strategy, but there is so much more to communities.  Consider these community models:

  • Forums – the traditional, continuation from the old BBS (bulletin board systems) and Compuserve Forums except that these are in an open network (Internet).  The idea is to offer a place to have themed, threaded conversations.  Most often used in service communities since is easy to segment by product and problem-type.
  • Wikis – although not generally thought of as communities, the fact that they can store knowledge and share it among their members makes for good communities where collaboration and content are more important that the conversations.  Yes, they do allow for conversations, but they work much better as content manager framework than as a conversation manager (forums are excellent for that),
  • Blogs – yes, they are communities.  Sure, they tend to be weaker than wikis for content management, after all there is only one author and the content is mostly static after publication, but the serve well as a tools to reach more and more people, and enter into conversations.  The threaded comments section is very similar to a forum, but the need for content before the conversation and the static segmentation by posts makes them not very efficient for lengthy, multi-topic conversation.
  • Newsletter – this is the perfect example of a one-way community used to spread knowledge.  It severely lacks on real communities options for two-way conversations and the spreading of knowledge from all members to all members, but it works very well for passive communities of people that tend to not get engaged and mostly read (you did hear about the 90-9-1 rules – right? newsletter cater to the 99-1-0 rule)
  • Offline – I know, incredible that I would mention a community that has no bearing on technology-driven implementations.  But that is because SCRM is NOT a technology-driven implementation, and if you follow the basic definition for communities I used, and the fact that organizations are trying to reach all the communities that influence their customers, offline are the ones that deserve more attention than online, since most people spend far more time in offline communities than they do in online communities.

After you select a purpose for the community and a model that caters to that purpose, you need to define the model of community you want to leverage.  There are three types of communities to choose from:

  • Task-Driven – short-term communities created and used for a specific purpose. Also called ad-hoc communities, they focus the interactions in a specific event or situation.  An example is a feedback community prepared for the launch of a product.  When the product is launched, the task is completed that the community disappears (although, sometimes it changes into a support community – but the conversion rates are not as good as recruiting rates for new support communities).
  • Objective-Driven – long-term, established communities with a specific objective (e.g. collect ongoing feedback, provide support).  They don’t have specific end-dates (e.g. an event occurring), and they have large quantities of active members participating in them.  Good example of this is a service and support community, where new members join periodically and even though the product may change versions or features, the community continues to provide support.  Over time it becomes a recognized element in the experience of owning that specific product.
  • Impromptu – these are the ones that show the most promise.  They come together without notice, for a specific event or task, and they are created by their members without prodding or help, there is not maintenance or rules to abide by, and the organization is not aware of their existence immediately.  The promise for these communities is for organizations to be able to capture real-time actionable insights that would change the way they act in light of those insights.  A sports game community built up and discarded shortly after the game, providing wisdom-of-the-crowds to coaches and analysts?  The feedback affected people can provide back to the company during a PR crisis?  The use of twitter during the recent Iranian elections?  All examples of impromptu communities with great value.  The best way to sponsor them is to provide the platform for communities to come together without notice, carry out their short-lived purpose, and then move on.

The community is the basis for Social CRM to exist and for Social Businesses to grow.  There is no social without the communities.

I know, you are going to tell me how social is all about the customer, not the community.  However, show me a customer that functions without a community and I will agree with you.  Would you rather aim for managing a relationship with a single customer at a high cost? Or would it be better to engage with multiple communities and affect the same customer via them in an organic form at far lower cost?

What do you think of this post? the entire series? is there anything I am missing in the series or here? are you working on your roadmap to SCRM? would love to know more about it…

The Roadmap to SCRM – Part 4 of 5

Part 1 – Introduction
Part 2.1 – SCRM-E2.0 Pivot Point
Part 2.2 – SCRM Business Functions
Part 3 – SCRM Rules Layer

We find ourselves now having to decide which channels (remember? Social CRM is adding social channels to CRM) we are going to use to deliver the business functions we picked earlier, and to fulfill the rules we agreed to use. The channel selection and deployment of any multichannel strategy has always been my favorite part.  The questions that you need to ask are so interesting (well, not the questions – the answers), and the information you collect can truly help you understand and see the value of the implementation.

Of course, that means that it is also a lot of work.

Remember when you read those “social media experts” and “social gurus” telling you to just try it? that if you start listening you will be ahead of the game?  I know you know this already, but they are way wrong.  Way wrong.  Just listening without a purpose can hurt more than it can help.  Biggest problem is that once you are committed to a channel (listening) it is very easy to get in, but extremely hard to get out.  You can lose reputation, trust, customers, and business if you pull out of a channel because you never took the time to figure out if it was the right one for you.

How about doing it right then?

I am going to share some of the tools I have been using for a long time to help clients decide whether a new channel should be implemented or not.  I developed these tools while I was at Gartner and have been using them, and updating them, ever since.

There are two parts to this, first the decision of whether a specific channel is the right one for any one business function you are trying to deploy.  Look at the following flowchart (we will go into details later):

Slide7It looks complicated, but it is quite simple.  There are seven questions you will need to ask for any channel or solution you want to deploy.  The first three are killjoy questions – the quickly determine whether or not the channel should be implemented.  The last four questions are planning and documenting questions – it is the answer to these questions that will help plan the prioritization of the deployment of channels (that is the second tool, and step, of my method).

Let’s look at these questions in more detail:

Need.  Is there a need by a business unit to deploy this channel? The need for a specific channel denotes a requirement that cannot be bypassed or replaced with an existing implementation or alternative solution (business requirement, strategic imperative, compliance are some need).  If the answer is NO, then there is no purpose in implementing a channel: if there is no need it will be impossible to allocate resources (people, time, and budget) to properly implement it and manage it.  If the answer is YES, there are still two more sine-qua-non qualifying questions.

Want.  Do the customers want to use this specific channel?  Either by conducting a survey, listening to direct feedback, or a combination of both the organization knows that the customers want to communicate with them via that channel.  A very common misconception at this stage (and one prevalent in today’s social evolution) is to assume that because the competition or other businesses are doing it the organization should also do it.  One of the intricacies in business is that a particular organizations’ customer base is very different from their competitor’s, thus the assumption that one has to do it to match a competitor is incorrect.  If the answer is NO there is no purpose in implementing the proposed channel as it won’t be used it.  If the answer is YES there is one more test to go before committing to implement it.

Fit.  Is there an architecture and technology fit between this channel and the organization’s plans and implemented systems?  This is not about being an isolated channel, more on that later, but rather to ensure there is a fit with plans, database rules and management plans, systems’ deployments policies, and IT support for the solution.  Sure, Twitter may be free to start – but how about when you need to scale to an entire department (as they did in Comcast, JetBlue, and Dell)?  Will your organization be able to support your needs and requirements?  You really don’t want to find out at the moment they can’t.  If the response is NO, unfortunately this channel should not be deployed.  If the answer is YES – congratulations! you are ready to plan for deployment of this channel.

Alas, you can now gather the information you will need to deploy a specific channel — and yes, you have to do this exercise for each channel you think that makes sense to deploy.  The next four questions yield very interesting responses.  Make sure you are honest when answering them, and also that you thoroughly document the responses you get — you will need that information to prioritize the deployment of channels and tools.

Plan – Do you have a governance plan in place – including social policies, entitlements and empowerment, maintenance and integration, and who-can-do-what? By the time you ask this question you are totally committed (well, as committed as being at square one actually is) to deploying this channel.  Contrary to popular belief, social channels are not free.  Sure, signing up may be free but they require lots and lots of commitment, patience, resources, money, time, and effort to make them work well.  If you are going to put your organization’s reputation on the line – can you really afford to be late with an answer (in some cases by days) because you had another deadline?  What if there is a need to track the interactions for compliance purpose and, sorry, excel is not enough — how are you going to do that?  Where do you go to find Subject Matter Experts to answer questions you cannot answer? Answering these questions now will give you an idea of the amount of effort and resources it will take to deploy this specific channel; that information will become handy when prioritizing the order to deploy the channels.

Silo – As you probably heard but never experienced, there are organizations out there that deploy new channels isolated from existing implementations.  There is a belief that maintaining two knowledge-bases and two identical (or supposed to be identical) sets of business rules is not that hard to to</sarcasm>.  Isolated, stand-alone channels stand as much chance of being successful as they do of failing in a very short time (i.e. is a coin toss).  We talked about integration for compliance before, how about integrating to provide the right answer in fast manner.  Agents, and other people who will use this new channel, will not look kindly to having to keep separate sessions with a KM or another system simply to get some information that then will have to be typed or cut-and-paste into the new channels they are supporting.  Deploying silos was not a good thing when the channels could afford to have some latency, or had some latency built in (e.g. email) – but it is a horrible idea to do so in a channel that moves in real-time.  If you don’t have an integration strategy worked out, this is the time to do so.

Strategy – Speaking of strategy, why are you deploying this specific channel? what is the purpose, the goal, the objective? do you have a vision and mission? how does it support other strategies in the business – including the overall business purpose and strategy?  There has to be a strategy to launch this channel – or any channel for that matter.  If you don’t have a strategy in place for this specific channel (and one that connects and relates to the previous rules and functions layers) get one.

PR – How are your users and customers going to know that this channels has been deployed?  As I mentioned in the strategy bullet point above, there is a specific purpose for launching this.  A goal, and a objective implies that it will benefit certain type of users and certain transactions — how are you going to make sure that those users and others who need to process that transaction will know that the channels exists and is deployed?  This is where the PR plan comes in handy: it will ensure that the right people come to the channel, use it, and the usage increases over time.

Congratulations!  You know have all the information you need to deploy a social channel.

Well, probably more than one.  In most cases you will be looking at three or more channels to deploy and varying degrees of need to do so.  The best way to select which channels will be deployed first, and which last, is to build a prioritization table that will include a description of the benefit to the customer, benefit to the company, and estimated time to deploy.

The following chat shows an example of a customer service channels decision matrix.  Yes, I thought about using one with specific social media information — but it would have ended up being quoted as accurate for every situation, every company.  I prefer to include a functioning model for you to follow and not one with detailed information to may be copied and not be accurate for any one specific situation.  Besides, remember when I said at the beginning that it was a lot of work?

If there is sufficient interest (i.e. requests via the comments section) I will work on one for Social Channels (plastered with caveats).

Slide8What you will notice right away is how you will use the information you collected in the previous flowchart to make these decisions.  There is some estimation work (especially in the value to the customer part, and some on the implementation times), but for the most part if you complete, honestly, this matrix you will notice patterns emerging that will help you decide which channel will be first (faster and more value to both parties), and which last (slower and lesser value).  The different combination between time to implement and expected value will have to be matched against your overall strategy, need to prove value or ROI in the short term, and specific pressures you may be facing from internal teams as to how to proceed.

Done.  We picked the channels and prioritized them.  All we have left to do is focus on which communities or customers we will affect with the deployment.  That’s next.

What do you think of the model so far? What about the channel selection? How is your organization taking on this concept?

Updated: Added link to next section for easier reading Part 5 – Communities Layer

Lessons Learned at the SCRM E2.0 Conference

Funny thing happened to me this week.

I attended the Enterprise 2.0 conference in San Francisco and an SCRM conference showed up.

It all started with the keynotes on day one:

  • Tammy Erickson from nGenera delivered the opening address (she did a great job) talking about the differences between traditional enterprise and Enterprise 2.0:  changes in society, people wanting to collaborate more and work together, using social tools to act on tasks and focus on the best way to achieve the expected outcomes.  She discussed the necessary changes in leadership and mentality of the users, how it was no longer sufficient to just do something – it had to present a challenge, provide satisfaction for a job well done, and deliver an innovative solution. She did mention users and leaders as the antagonistic characters in this play (replace user with the word customer, leaders with the word company — and we have SCRM)
  • Rob Tarkoff from Adobe said he was going to talk about — wait for it — Customer Interaction Solutions.  I was slacked-jaw, speechless, and teary-eyed at the same time: can the good people of E2.0 really care about the customer? He did make a pretty good case for mashing up SCRM and E2.0 (of course, without calling it that) and very much aligned with what I have been trying to say with my darn, polemical pivot-point.  His conclusion? Enterprise 2.0 is about serving customers better – not users working together better (good, controversial for the audience).

    At this point I looked at the name of the conference inscribed in my badge to make sure I was in the right place. These are the issues we’ve been discussing: customer(user)-centricity, fulfilling and surpassing customer(user) expectations, using collaboration with customers(users) to accomplish the goals, and changes in leadership and mentality to adopt this evolution of the social customer(user).

    Other sessions I attended (even if you don’t count two panels in the last day talking about how to do customer service better) all talked about the same issues but without mentioning customers.  Apparently, Enterprise 2.0 is not done for customers’ benefit – just for internal users to work better together.

    The Customer is the red-headed stepchild in the family — no one wants to talk about them, but you cannot ignore them either.

    There was, however, a key difference: most of the conference was centered on tools and deployment, approached from an IT perspective.  We talk about strategy, from the business stakeholders’ perspective.

    This is the gap we need to cover. Convergence must be our new battle cry.

    Issues are very similar, if not the same, and technology is the same, if not very similar.  There are just two “thingies” to fix:

    users versus consumers – we need to remove that invisible shield that separates IT and Customers.  Customers are willing to work with us if we let them, and (most) users understand that it is about customers.  The talking heads in the middle (yes, I am as guilty as the next one) are muddling an issue that should be very clear: one company, one solution.

    strategy versus tactics – we need to get past this mental barrier about what it is that we need to do.  It is not about buying a tool and deploying it – we tried that with regular CRM and failed.  It is also not about crafting an awesome strategy and never implementing (ibid, CRM).  It is about customers and users creating together solutions that focuses on what the customer needs and what the users wants to accomplish. Then, get it done. We must change the mindset to make things happen; we are all after the same holy grail: happy users and customers.

    Were you there?  What did I miss?  What did I get wrong? Tell me how we can make it all work…

    Related Posts – you must read Nenshad’s summary of the conference.  He nails it.

    The Roadmap to SCRM, Part 3 of 5

    Part 1 – Introduction
    Part 2.1 – Pivot Point
    Part 2.2 – Business Functions

    It is important to recap a couple of things that we said before:

    • The SCRM Strategy is composed of multiple sub-strategies, some of which you may already have in existence
    • The roadmap to SCRM is an iterative process, where you will re-visit many times each strategy and sub-strategy

    Why am I emphasizing this? Because we are now at the rules layer of the model. There is no physical or quantum method you can leverage that will get it right the first time.  It will take several passes at each, improving from the good (and bad) experiences.

    First, let’s bring up the chart on how to create a SCRM strategy for reference:

    Slide2The rules layer is simple to explain, but takes a lifetime to master.

    I won’t be able to do it justice in one single post and I don’t think I could address all the issues and questions in one sub-post for each.  This is becoming part of my research agenda for next year.  This post is only going to briefly touch in the high-level issues that affect SCRM, but more details will come next year.

    The following chart shows the six different sub-strategies for the rules layer – in the order you should tackle them (from the inside out):

    Slide5Segment – The  different groups of customers affected by a business function.  The critical aspect for SCRM is to go beyond the traditional revenue- or profit-driven segmentation and begin to consider social function, social channels, even reputations and rankings in different communities when building different segments.
    Business Rules – Rules that govern how each of the business functions and processes will execute.  Some business rules may be mandated by compliance, some are controlled by industry-wide practices you must support to remain competitive.  Business Rules are implemented in conjunction with the other layers in this model, they cannot be implemented separately.  Social considerations for rules are aligning them with the policies and stated positions to become a social business.
    Service Level Agreements – Service Level Agreements are about managing customers’ expectations.  SLAs are set at different levels by channel and segment.  Social considerations for SLAs are to adapt the delivery of specific functions to the new social channels (promise what you can do, then over-deliver.  If you cannot do, don’t promise).
    Measurement – A measurement strategy is about the internal tools and metrics used to measure efficiency of business functions.   This is  done by correlation of metrics from the front-office processes (effectiveness metrics usually) with back-office metrics (performance metrics traditionally).  Social Considerations for measurement strategies are to accommodate the new metrics and KPIs for the newly deployed channels.
    Feedback – Feedback is the external tools and metrics to measure effectiveness of business functions.  Deciding at what part in the process to collect feedback, and how to use it to measure the effectiveness of the process from the customer’s perspective, is also closely related to the Analytical sub-strategy. Social aspects of the Feedback collection are related to the inordinate amount of data collected in the new social channels and how to use the social channels to collect feedback.
    Analytical – This is where a large part of my research will be next year.  The idea is how to control the very incredibly large amount of data and feedback collected in unstructured form, and use that to further the business.  This sub-strategy is about figuring how to create actionable insights, and what to do with them in a social business.

    How does it work all together?

    Building sub-strategies independent of each other will not yield any advantage over today’s methods for collecting and using data.  The key to using these components to create actionable insights is to focus on the client-expected outcome and mesh that to an existing or created experience, then look how the six elements above describe that process.

    An example, if you are going to implement technical support:

    1. are you going to do it for all segments? who is entitled to it?
    2. how are you going to deliver it for each? what is the result? what data will you need? what data will you produce? how will you manage it? what will the results be? what business rules will apply to this function? for each segment?
    3. what service levels are you aiming to achieve? how will you set expectations? how will you manage those expectations?
    4. how will you measure the success? what metrics will you use to measure success? how will you know that the process is working internally?
    5. will you collect feedback? how will you know you are doing a good job? how will customers be able to improve the process? how will you use the feedback you collect?
    6. what insights could you gather from the completed process? what will you do with them? where will you apply them? where will the feedback go within the organization to become useful? how will the customers know they were listened to?

    This is the point where you go back to the beginning of this post, scan through it again and come back to this exact point a second time and say

    What is the difference between doing this and doing a traditional CRM implementation?

    Some time ago I wrote my first post in SCRM.  The title was “Don’t call it Social CRM – just add Social to your CRM“.

    Building a SCRM strategy or deploying it is no different from building a CRM strategy and deploying it – except for two tiny, tiny details: the volume of feedback you collect has increased by magnitudes in excess of 100X the original feedback you used to collect via surveys (and it is unstructured), and the emergence of communities (try a different mental picture).

    This picture will give a more clear detail of what matters in SCRM — and also show you the reasons those two items are my research agenda for next year.

    Slide6

    So, what do you think?  Any questions so far? Are we moving closer to mastering SCRM? Are you more confident about success with it?

    Updated: Link to next part for easy reading Part 4 – SCRM Channels Layer