While I don't have any specific guidelines I can share per se, I do believe that one of the most important things you can do is to always always put yourself into the customer's shoes. I used to be a Jive customer so it's fairly easy for me to take that perspective... Am I giving this person an answer they can use, even if I don't know the answer? Am I pointing them in the right direction, connecting them to the right people that can help? Does the way I've set up the community make sense to the customer so they have the easiest experience possible?
Depending on what business you are in and how complicated your product lines, you could set up a few of the main customer use paths as a guideline then build your support model from there. It's good to also start with the business processes already in place for customer support to make sure they are built into the community in a way that makes sense.
One other great place to post this question is in our Jive Professional Services group. We have PS people there who can tell you if there are indeed best practices for customer care that have been doing this a whole lot longer than I have. Good luck!
Boy - that is a "big" question! And without meaning to be flippant my answer would be "what do you want to do"?
Let me explain by citing a few of the most-common external support community use-cases.
Product support, knowledge and usage extension: Some companies want their customer-facing community to be one where heavy-duty product support and discussions take place. The customers themselves take the lead in these communities supported and surrounded by company subject matter experts and product support people. Companies who have successfully done this on Jive include Solarwinds with Welcome | thwack, ESRI with Welcome | GeoNet, Tableau with Welcome | Tableau Support Community and others. These communities are differentiated by lots of very hand-on "how-to" information. The organization is often by product type. The community "heros" often are not employees of the company but rather are customers of the company. Company product managers make frequent guest appearances and are often called upon to "settle" points of dispute ("is the product supposed to do X or Y"?) and are the product "voice" of the company within the community. Community managers connect customers with the right people and places to get their answers.
Product Pure Technical Support: Some companies use their communities as the first place customers go for support. Usually the question that a customer has already been answered in the community. Any reasonable search will usually lead to the answer. This means the customer gets a quick answer (no matter what time of day or night) and the company reduces the cost of their technical support. Community moderators make sure that questions get to the right area, guide customers, aggregate questions and answers, identify common problems (and hopefully escalate to engineering), generate FAQs to take on the most important problems, etc. This is a very transactional-type community with a goal of answering customer inquiries as quickly as possible. An example would be DIRECTV with Welcome | DIRECTV Technical Forums and T-Mobile with Community | T-Mobile Support.
Marketing, product reach and extension: Some companies use their customer-facing communities for more marketing focused services. These communities are about spreading feature and benefit based information, allowing customers and potential customers to learn about new products. This is a deeper version of a product-focused micro-site and is particularly useful where a lot of Q&A is a necessary part of product selection and adoption. The company typically has product managers and deep subject matter experts available to support these sites in addition to community managers. Broadcom has such a site at WICED™ | Broadcom.
So to get back to your question - what do you want to do with your site? The best practices will depend on the business outcome you are looking for.
What an excellent question! One of our key drivers is to deflect cases / provide more self-service. Whereas the strategy is for customers to help customers, the CCARE group is feeling some pressure to respond quickly as well as to provide valuable responses whether the they are a premier customer ... or a guest.
This was the specific ask:
As we venture into the communities we should set up guidelines for Tech Support folks to use in debugging situations. As an example info requests, workarounds, managing complexity, are great to use for communities, but working on production down, defects or internals would not sound correct. We also want to make sure our stature as internet experts is maintained in our exchanges and not seen as passing the support buck to communities.
Thank you for the examples.
Great - so there are a couple of different models that you can use as a jumping off point. One of them is right here within the Jive Community (known to the cool among us as "the JC" ).
I'm going to re-characterize what you said. Here is what I "heard"
- We need to handle "...info requests, workarounds, managing complexity..." I would characterize these as "discussions that are OK in public, probably not a 'case' "
- We need to handle "...production down, defects, and internals..." I would characterize these as "discussions that should be handled privately and need a 'case' to track them"
- We need to make sure that we maintain our reputation as internet experts and not take the risk of "passing the buck" I would characterize this as a necessary service level approach and promise
- Finally - we don't think that numbers 1 and 2 are probably handled in the same way with the same public exposure Making explicit what is implicit
Within the JC there are lots of public places where customers can have open discussions (like the one we are having now - Jive Internal Communities, Jive External Communities, Jive Developers, Careers Using Jive, etc, etc). Depending on what you are interested in you find the right place and jump in. People like Libby Taylor get you to the right place and connect you to the right people/assets. These public places harness the power of community allowing your customers to exchange ideas and information freely - spreading best practices quickly with low investment on your part.
Also within the JC each customer has a secret support space. The customers can invite whoever they want to the space (it is usually a pretty limited list). When an issue comes up that is unique to that customer, then the customer "raises a case" in the support space. Jive responds appropriately (education, config change, bring in engineering or professional services, whatever). These spaces keep confidential information limited to only those with "need to know". On the upside you can contain negative events within a small group; on the downside you lose some community leverage since your internal support team will wind up handling a common problem as a cascading series of one-offs.
We have also done configurations for customers that are a hybrid model. We create spaces or groups for them that are around a particular topic area. Their customers can raise questions in those topic areas. If the question isn't answered within a (configurable) amount of time (say, eight hours) then we automatically raise a case for them in whatever the case tracking system is (typically Salesforce or ServiceNow). The technical support group then manages the case "normally" (typically within the case management system) and we post the results back to the original question in Jive. So the solution that the internal support group comes up with becomes a permanent asset that can be used by anybody else with a similar question/problem in the future. This model allows customers to quickly solve each other's problems; if the problem isn't solved in an acceptable amount of time the backline staff steps in with the "big guns" and resolves it. The extra transparency here is both a benefit and a risk; if you have a major defect in your system your customers will "out" it pretty quick. If you handle these events correctly they quickly become a strength within your community. If you handle them wrong they are a killer.
One of the reasons we are such huge fans of Jive (I'm not a Jive employee) is that Jive allows you to do all of the above within one instance; it is all in the configuration.
My two cents:
Overview: We are into healthcare equipment manufacturing and we have setup a service portal using Jive; it is used only by our customers and employees (no guest access) right now. Upon purchasing a product, the customers are granted an SSO id to log in to our portals and they will be welcomed by a landing page with important news/announcements/links. From there, they can access their product pages (individual spaces maintained for each product and access is controlled by permission groups).
Customer Support: Each product page would generally hold important documents/announcements/discussions related to the product and also links to relevant sub-spaces for the business. Customers collaborate on these contents and find resolutions fast. If required, they can raise a support ticket using our own ticket logging and tracking applications. Either links to those apps will be provided on product page or it will be iframed (direct view within jive) in sub-spaces. If you don't have any apps of your own, consider integrating a case content type with the help of Jive PS team.
Community Management: Product owners identified from employees will be granted space admin rights and they are entitled to monitor their product spaces, moderate content, manage users and respond to customer queries.
With proper workflow, integrations and permission setting in place, we are successfully utilizing Jive as support site much appreciated by our customers.
Another example I can share you is apple's discussion forum: Welcome | Apple Support Communities