Customer support organizations were the earliest of adopters for CRM systems. Thanks to call center software and the need to drive cost reductions and faster service turn-around cycles, the customer support organization developed solid business processes, comprehensive measurement and good discipline. But that's all so last-century.
All those customer support disciplines, metrics and best practices were developed when the relevant parts of the web were static HTML and email. Social networking consisted of majordomo list management. All the social power of blogs, wikis, Facebook, Twitter, YouTube LinkedIn, social media metrics and reputation management hadn't been invented yet.
And those things really matter to customer support, whether you're talking about consumers or businesses. Social media can magnify and accelerate customer dissatisfaction problems, taking them to global scale in just hours. In the political realm, this effect took down several despots last year. For companies, a web firestorm about customer satisfaction can develop overnight and if you aren't paying attention, out of your view and control.
Worst Practice #1: Ignore Social Network Effects
There's been tons written about social media for the marketing and sales departments, but until recently there's been less about these issues for the customer support/service teams. There's a
terrific posting here if you want a quick read, but watch out: The topic is fractal, and you may end up going way deep into community shepherding, reputation management and other neat time-sinks.
The cloud by its nature encourages social network effects, so your support organization needs to get these basics under control:
• Customer portal(s) to exchange product/service information in a controlled way (gated community) and collect as much structured Case/Incident data as you can.
• Forums and community management to accomplish the following:
-- harness the good side of customer self-support (particularly, having a "guru" program to encourage customer contributions to solutions, best-practices, and workarounds), and
-- contain the negative effects of the forum echo chamber ("we reported this bug 3 hours ago, we can't believe it isn't patched yet this product just sucks!")
• Multi-channel communication to "support customers where they already are." Phone and email and web just aren't enough, particularly for a web-savvy customer base. You want to require as few "hops" as possible during a service issue resolution, working with customers via IMs, forums or whatever communication medium they are in. Salesforce.com's chatter strategy is a great example of reaching out to customers in a social network that is still a walled garden.
• Reputation measurement and management to understand how customer sentiment is going, and measure your corrective strategies (hint: this is an area ripe for split testing). Make sure that you are tracking your statistics separately for what's going on in your walled garden vs "the public view." You don't want to be surprised by a fire-storm in Yelp, PowerReviews or BazaarVoice review sites.
• Regular broadcast communication to let people know about the state of your overall product / service ("99.8 percent of customers are within our SLA") as well as particular problem areas ("Bug 12345 has patch ABC which is in final test with 10 customers--will go to general production system this weekend").
Worst Practices #2: Overdoing it with Social Networks
Moderation, right? Well, that's part of the story. Not all of your customers are all that web savvy, and some of them really want to be communicating over the phone. So make sure that the old channels of communication (including quel horreur postal mail) are still working well for your support business process.
But at a more fundamental level, social networks should not be used for the initial opening of a case or incident. Why?
• Social networks have problems with ambiguous identities (is DavidTaber on Twitter the same as DavidTaber on Facebook and the same as
dtaber@saleslogistix.com ?) that can make things difficult when trying to track down support entitlements or warranty info.
• Social network communication is inherently unstructured, just what you don't need when it comes to opening a case. For example, a user might be having troubles with your cloud application, and you need to know things like browser type and version, mobile platform (Android vs Apple vs WindowsMobile), and other parametric information. Without this structured information, there's almost no point in opening the case at all. The result of opening a case via social media is a long back-and-forth with the customer, wasting their time as well as yours.
• A social media encourage sloppy, terse communication. 140 characters is kind of limiting when you're trying to describe an error condition. Again, this does nothing but waste the customer's time and yours.
While social media communication is fine once a case is opened, the starting point for good case management has got to be a well-structured communication. A web form is an obvious answer, but best practices for cloud products/services is to put the case initiation right in the service itself, with a "report a concern" button available that provides user-state and context information automatically & along with the bits of structured info you have to ask the customer to fill out.
0 comments [10]
[2]
[11]
