I shared with you the first of four top-level insights gathered via the research I conduct every year (thanks to the sponsorship of my friends at KANA, a Verint company). If you have not read them, you can read the high level entry here.
I am today going to start sharing the first of four blog posts to deal with the questions that are in most users mind these days (based on inquiries I get): mobile, social, operations and adoption. After we post these four I will then publish the final report with all insights and data (likely end of January or beginning of February). Stay tuned.
As you likely know, I am not the largest and most ardent proponent of Social Customer Service. I have written plenty against it – all substantiated with data and case studies; I won’t start again…
OK, just a summary:
- Twitter acknowledges that virtually all tools miss tweets from the “fire hose.” The volume is just too much for most solutions to capture, analyze, and categorize in real time (it is possible, just not done well is the point)
- Facebook continues improving their platform (not including privacy and ownerships rules, which are a topic by themselves) but they fail to notify developers that depend on existing APIs – thus rendering entire applications unable to connect without due notice or warning
- Over 80% of contacts via social channels end up being escalated / diverted to a different channel for resolution
- Over 50% of incoming tweets and Facebook messages (and this was before the switch to Facebooks messenger – which will bring another slew of problems) are not addressed, ignored, or abandoned before resolution by the brands
- Integration between social solutions and the rest of the customer service channels and processes is ill-fitted (if done at all) and unsuitable to manage the expected loads as usage increases
In spite of these challenging statistics, and the lack of a significant number of successful case studies to refer to beyond the simple “anecdotes” that show it can be done Social adoption continues to be adopted at a fast pace.
In the first version of this study, carried out in 2012 during the height of the “craze” of social, we saw small and early adoption rates (Twitter was 25%, Facebook was 26%). The following year, when we had already made some inroads into understanding the numbers above, and the lack of an integrated solution made it hard to justify to management, adoption continues strong – albeit at a slower pace.
This year? Still being adopted in large numbers.
When asked about latest channel implemented, 11% said that Twitter was the one and 18% said Facebook was the one. When asked about channels that are implemented 59% said they had implemented Twitter and 58% said they had Facebook implemented.
When asked about the most used channel (a new question we incorporated this year) we noticed reality set in: neither one of them scored even a single vote. And while we don’t have historical information to contrast with – it is important to notice that it is still early and we have not yet figured out how to use them properly.
Why is this happening?
Follow up interviews and existing inquiry data yield an answer: virtually all practitioners that have implemented and continue to implement social customer service say that it is because their customers demand it. When pressed further for details on how they know what their customer demands are, their answer is what troubles me.
They did not ask their customer, or did not ask properly – but that is fodder for a different post. Whether being served via social was something they needed or wanted, instead they assumed that since their customers were using those channels they wanted to be served via those channels.
This is the most dangerous assumption to make: you need to be where your customer is. Customer enjoy using social channels for different reasons – but it does not necessarily mean they want to be served there. As Facebook and Twitter have shown when attempting to conduct commerce directly via those channels, there is no demand just because they are there.
I wrote sometime ago an editorial advocating for single-channel excellence over multi-channel cacophonies. It is still true today. The main concept was that offering more channels, poorly, is not the approach to customer service.
Offering social, just because it is possible or because customers use social channels, is not a good idea until we can master the essential elements of how to do it well:
- Resolving issues without escalation
- Automating standard inquiries and responses
- Integrating into existing components (like KM) and other systems of record
- Deliveing consistent solutions and answers via all channels equally well
If you want to deliver social customer service find out how you can tend to those four elements before you get too far. Else, you will be simply adding a layer of complexity, an element of cost, and a broken customer promise to your customer service implementation.
There is another element of social customer service that is somewhat disconcerting: when asked if they saw value to the organization and to the customers when delivering social customer service almost one out of four organizations said they did not see value to the customer (and in line with the last two years’ findings). The question begs to be asked: considering the issues above, and the lack of ROI and / or value experienced – why would anyone think that social customer service must be deployed?
What are you doing with social customer service? Have you implemented yet? Have you found the answers to the above?
Would love to hear what you are doing, and your comments on this as, well.
Disclaimer: KANA, A Verint Company, is a client and the sole sponsor of this research report. While they get input into the topics to survey, and provide feedback on the thesis before we start, the final decisions on content, questions, and analysis remain mine. There is no input from anyone else other than thinkJar and its employees (which, as you know, it’s just me) in making content and editorial decisions on the study, findings, and reports. All data is propriety of thinkJar and not shared or distributed.
(Cross-posted @ thinkJar)