Your customers have greatly evolved since the previous internet bubble, while most company’s customer support models have not grown with them. New, “Web 2.0” paradigms for content creation, publication, syndication, and consumption bring with them an enormous innovation opportunity for businesses needing to talk directly to millions of customers.
Because of this gap between customers’ needs and current offerings, up to 80% of your customer support budget is potentially being wasted. Currently, that money isn’t improving customer satisfaction, driving market share, creating buzz, generating great content, or (most importantly) helping customers be more successful. Most companies current support models no longer match the expectations and behaviors of your customers.
Today a huge percentage of our developer product support is delivered through traditional 1:1 phone connections. My goal is to flip the ratio to a 90% focus on “many to many” customer connections and further our support dollars to touch a larger customer base. It should become an exception when a solution given to a customer from Microsoft is a private conversation, and it should be the norm that solutions are published into our customer communities.
With this goal comes its share of challenges.
1. Culture Shock: Customer communities have been largely ignored in the past. They’ve developed their own culture of free assistance, codes of conduct, and rules that most support organizations have to adapt to. We’ve seen these growing pains first hand while introducing our support staff to our volunteer moderators. A classic example of this is a support org that wants to answer every question and customers that don’t want to do homework for students. The community is right. Your support budget shouldn’t do homework for anyone. J
2. Mixing Paid & Free: Classically the stance that’s been made is “Post in our communities and take your chances or call us and pay”. If you want nearly all of your product support handled in public it means handling paid support in public as well. Clearly there would be value in sharing all the knowledge gained from paid support questions with customers but it also would make it seem like we would be doing so to off-load our support burden to our customers in order to reduce call volume that’s costly. How do you rationalize paid work in a world that’s been volunteer driven? I’ll have follow-up posts on potential solutions.
3. Making Public Mistakes: There is a safety net in 1:1 support. If the answer given by a support technician happens to cause data loss over time then at least the damage is localized to one customer. If the same answer is given in public is has the potential to cause data loss for hundreds of customers and then you’ve got a big problem. Your support organization probably prides themselves in having high customer satisfaction and sorely want to avoid causing dissatisfaction through transparency.
4. Support Contracts can Make you Money: Not all support costs you money. What if you have a model for support that is either a value add for your product that sells more products or if you actually use product support AS your revenue stream?
5. Tools: Most community sites aren’t built around enabling both ad-hoc free for all assistance, discussion, AND paid support scenarios. If you look at the problems we’ve been having lately with our forums you know that these challenges aren’t insignificant.
6. Being Agile With Support: Your customers expectations change quickly so your support process needs to be flexible enough to handle it. Typically, in an outsourced support model you define a very strict process and set of rules so you can make it simple enough to save money and hand off to 3rd party vendors. Today your customers may expect support in forums, but tomorrow they might expect you to chat with them in real time right when they have the problem. You have to have a way to adapt support process more quickly.
7. Who organizes this customer engagement: Is it really just a challenge for your support organization or should the people that make the product be accountable for the issues encountered with its use? That’s why there is no simple answer to Bill’s challenge. Viewing community engagement as purely a support or purely as customer marketing engagement is wrong. It’s every organizations opportunity.
8. Classic Support Metrics Don’t work and even new ones need tweaking: Measuring per incident customer satisfaction, time to resolution, and engineer utilization efficiency doesn’t work in public. You aren’t answering a question just for one person, there is a different quality versus quantity balance, and rigid metrics don’t generally allow for the agility that’s required with doing support in many to many environments with the help of customer experts. We’ve tried measuring community answer rates versus Microsoft answer rates and I think they are better than some other metrics I’ve seen the numbers have caused problems with users marking answers aggressively.
9. Your product has to be supportable and worth being supported: Don’t throw crap over the wall and expect people to help you sell it. It takes the right product, the right amount of customer interest in the product, and the right amount of knowledge transfer that starts to customers the day you start on the drawing board for your product.
I hope this starts to define the problem for people. Now I have to start answering these questions before 761 turns into 100,000.
What do you think? What challenges would you face if you had this goal? What should I be worried about?