9 Challenges to Making Product Support Transparent

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?

Comments (5)
  1. Wolf Logan says:

    As regards point #4 — that’s an interesting question. In the open-source world, "support" (in the form of consulting) is pretty much the only revenue stream. The general rule there is "check the Internet for information first, then ask on a public forum, then locate a consultant". The consultant will usually be able to work out a solution, for which effort they will be compensated, but the results of their work are usually folded back into the original project as an update.

    This process generally leads to 1) basic and common information being widely available, 2) simple problems being solved in public view, which eventually will be archived as "basic and common information", and 3) solutions to tougher problems being worked out and tested in private, with a rapid turnaround on distributing the new solution to whoever wants it.

    Now, this model is predicated on "support" being provided by "developers" (that is, the same category of people who are creating the product). This isn’t generally possible in an environment as large and complex as Microsoft, but having the developers alongside the support folks in the forums is a huge step forward.

  2. MSDNArchive says:

    Wolf: Yup, essentially I guess your looking at it from a Microsoft consulting service angle, but done more in public with ther solutions. That’s an interesting angle.

  3. betsya says:

    Another challenge…the cheap out syndrome

    When I saw the CEO of Zappos speak at South by Southwest, he made a really important distinction. At Zappos you don’t get the cheapest shoes around – you get the best customer experience and selection That’s because Zappos pays their people decently, treats them right, etc and they can’t cut costs without sacrificing this culture of uncompromising customer support.

    No, this is not an ad for shoes but a reminder that in the zeal to cut costs on support , companies may cheap themselves out of a differentiatior that allows them to survive competition. Sometimes the idea is – oh we will cheap out by having "the community" do it. Well, that may backfire on you and with cheaped-out framework  you won’t have the money to pay customer support.  or you may annoy your customers so much, they leave.

    It seems like if you make the effort on both fronts – to engage customers and also give solid customer support – it exponentially rewards the business by attracting new customers while creating an environment of helpfulness where "the community does it" naturally. That’s why the mix you have going is so interesting. People can find it all in one place.

    Keep us  posted!


  4. Cory Foy says:

    "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? "

    I just posted a couple of days ago about this very topic:


    This quote sums it up:

    "Quality in real money terms (and that is the way we keep score in business) is the inverse of the expense of technical support. If technical support is a profit center, then quality in the terms you think about normally are inverted. Therefore, if you wish to have high quality, you should ensure that technical support never becomes a profit center."

  5. Dick Carlson says:

    Giving customers easy access to information is a support area that some companies do well, and some companies don’t.  It’s really important that when people have issues with a product, they can quickly find answers.

    SEARCHABLE  Customer resources need to be tagged with words that actual humans would use in describing the product.  There should be very little technical lingo, product marketing, or "executive suite" words involved.  Ask ten of your users to describe a recent issue, and the words they searched on.

    DRILLABLE  Looking for information is often more than a one-step process.  Does your system allow me to refine searches, does it suggest alternate spellings, does it provide meaningful cross lonks?

    FEEDBACK  You should be capturing the backend information from customer searches, identifying the top five, and using that to build your next version as well as develop training and learning materials.

Comments are closed.

Skip to main content