Support guide

From Dreamwidth Notes
Revision as of 13:18, 1 August 2014 by Kaberett (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This page is a braindump page for the Dreamwidth support answering style. It isn't entirely complete, so please feel free to update as necessary.

For technical details on how the Support Board itself works, see Support process.

Dreamwidth's support style

Dreamwidth's support answering style can be summed up in 4 points:

  1. Be courteous.
  2. Be professional.
  3. Be human.
  4. Treat everyone as though they're the most important user we have.

The fine points, of course, is where all the details lie.

Points to consider

General phrasing

  • Speak with a human voice. You're a person; the person on the other end of the screen is a person. Support answers should be person-to-person and human-to-human, with a tone that is both respectful and friendly. Your answers should sound like your voice -- the way you personally would explain something to a coworker or a professional contact. Don't be afraid of contractions or the word "I".
  • Responses should be addressed as "Dear $name" (where the name is any name that they provide, or their username if they don't sign one), and signed with your name (whatever name you'd like to give). You can use any signoff you'd like, such as "Regards," "Best," or whatever signoff you feel most comfortable with.
  • A casual tone is okay, but at the same time, casual can translate as "insulting" across cultural boundaries and through language difficulties. Triple-check to make sure that your answer doesn't sound condescending or insulting. You can read the Manual of Style for specific advice.
  • Apologize for anything that's frustrating the user, but don't make it into the user's fault -- "I'm sorry this is frustrating" is okay, but "I'm sorry that you feel this is frustrating" is not. (The former validates the user's feelings; the latter places the blame on the user for feeling frustrated.)
  • Light wittiness in answers is okay if the user is approaching us in that tone or style, but humor doesn't translate well across cultural and subcultural boundaries, so try to avoid it unless you have reason to believe that the user will be receptive.
  • If a user has a point -- if things are difficult to understand, confusing, or not explained as well as they could be -- explicitly acknowledge the point, without getting defensive. (This applies double if the user is frustrated, upset, or angry.)

Terminology to use

  • Work with the user's chosen vocabulary as much as possible. If they call something by a name that's not entirely accurate, work within their terminology as much as possible without being actively misleading. (If you want to know what the "official" terminology is, refer to the Terminology page.)
  • Tailor your answer to the user's experience level. If you aren't sure what the user's experience level is, aim for as basic as possible, and be sure to acknowledge that they might already know what you're saying.
  • It's all right to use technical language, especially if it helps to clarify, but be sure that the first time you use any technical term, you define what the term means. (It's okay to do this in an aside or a parenthetical.)

What about bugs?

  • It's okay to tell someone that something's broken and that we're working on fixing it.
  • If you're going to tell someone that something's broken and that we're working on fixing it, make sure it's in Github Issues first.
  • If something's broken and it's not in GHI yet, take ownership of getting it in there if you're going to answer the request.
  • When answering requests about a bug, please put the GHI URL regarding the bug into an Internal Comment.
  • Avoid putting the GHI URL into the Answer unless the user has expressed an interest in fixing it themselves or has specifically asked for the GHI URL. Situations where the bug has had a fix checked in to issue tracker but it is not yet live on the site have caused confusion in the past.
  • Set expectations accordingly. If something's prioritized for the next milestone, you can tell the user that. If something hasn't been prioritized yet, tell the user that it's in our bug tracking system, but we haven't set a date for when we'd like to fix it.
  • Remember that everyone uses the service in different ways. If the user is asking how to do something that you think is a "wrong" use, it's probably not; it's just a use that we haven't thought of yet. Make sure that someone knows what the user is trying to do, so they can consider implementing it.

Possibly answered elsewhere

  • If the user has mentioned that they've already read the FAQ, don't send them to the FAQ without acknowledging that they've already read it.
  • It's okay to say something like "Before we go into advanced troubleshooting, I'd like to just rule out some of the most common causes of this problem. Can you confirm that you've already tried $commonsolution, and let me know what happened when you did?"
  • Use your best judgment when choosing whether to rephrase the material in a FAQ for the user.

More info needed

  • Never be afraid to ask the user to clarify something. If they're asking a question that could be X, but might be Y, answer X, but say "You might also mean Y. If you do, here's the quick overview, and if that doesn't answer your question, let us know."
  • Never be afraid to ask the user for more information. If they say "X is broken", don't be afraid to say something like, "So that we can diagnose the problem, can you tell me exactly what happens when you try to X?" (Of course, be sure to go and try X yourself first, to see if you can figure out why the user thinks it's broken and save some time.)

Unasked questions

  • Respond to both the question the person is literally asking, and the one that they don't know that they need to ask. Answer the question they've actually asked first, and explicitly.
  • Aim for answering all of the user's questions (even the questions they don't know they need to ask) in a single contact, but don't worry if you can't get it. If you ever think that you might not have given them a complete answer, if you think that they might have more questions, or if you're offering them a fix that might or might not fully solve their problem, include an explicit invitation for them to come back to the request and let you know if it doesn't work.

"But Whyyyy?"

  • Explain the reasoning for why things are the way they are, without coming off as sounding like those things will never change. If it is something you think will never change, confirm it with someone first, then link the user to the official explanation of why things are that way. (If there isn't an official explanation of why things are that way, poke someone to make sure that it gets written.)
  • If the user doesn't like the fact that a particular thing will never change, or that it won't change for now, acknowledge the validity of their not liking it and let them know, in as courteous a method as possible, the reasons for the decision. Not everyone will like every decision we make, but they deserve to know the reasons behind the decision.

"Hasn't this been answered 50 times already?"

  • We'd rather hear about something for the 50th time than not hear about it at all.
  • Even if it's the 50th time you've answered that question today, to the person who is asking the question, it's the first time they've asked it. Respond to the 50th question as though it was the first.

Third-party tech support

  • Some importer and crossposter stuff requires knowledge of how the other sites work.
  • Some client questions require knowledge of the clients.
  • The full policy on support that involves third-party stuff needs better documenting; when in doubt, ask.

General stuff

  • Remember that there is always room for us to improve.
  • Everyone has a different learning style. Some people need text; some people need diagrams; some people need step-by-step detailed instructions. Tailor your answers to what you can divine of the user's learning style as much as possible. If you're having trouble getting across to someone, grab a friend who has a different explaining style and ask them to take a stab at it.
  • People will take your words, your gestures, and your actions as an official communication of Dreamwidth Studios, even if all you're doing is explaining how to confirm their email address. For many people, you will be their first and only contact with us. Make the impression as positive as you can.
  • Go the extra mile. If there's something you can do to make things more awesome for the user, whether it's contacting the site copy team to make instructions clearer, pointing them to an official community with more information about their problem, pointing them to an unofficial community that offers resources they might be interested in, or logging a bug to get their pet peeve fixed, do it whenever possible.
  • If the question is being asked now, answer it now, even if the answer is "We won't have an answer for that until later". Be sure to define "later". Also, be sure to come back and update the person when that thing happens.

Workflow

This is a description of the usual steps in successfully and fully answering a user request. Everyone has a slightly different process, and all steps are not necessarily done in the same order.

  • Select a request. (You don't necessarily have to commit to answering the request, just find one that looks interesting to you.)
  • Read the whole request.
  • Figure out all of the questions being asked and/or issues being brought up.
  • Find the answers to the questions, address the issues, and/or direct the query to the proper area.
    • Look through FAQs, both general and Issues.
    • Search Github Issues
  • Gather any FAQs you will be linking to the user.
  • Write down the answers to be sent to the user, in accordance with the support style.
  • Review any FAQs to make sure the information that will help the user is still there; FAQs are subject to change and revision.
  • Make an internal comment linking to anything in Github Issues that you reference in your answer.
  • Work collaboratively with SupportHelps and others and revise as needed. http://dw-support-training.dreamwidth.org/4499.html

Support resources

Questions & Feedback

You can ask questions about general things or specific situations.

General

A list of some resources that you may find useful for support can be found here.

If the issue seems to be browser-related, see here.

"Model answers"

The following is some information put together to aid support volunteers in answering questions. Obviously, don't copy and paste what they've written as is, as it doesn't exactly follow the support guidelines right now, but anything linked here should have been okayed for use in support answers by the author and so you're free to use this information, edited it as necessary, in support answers. (Please do not copy this information as is - personalise it!)

Current Issues

Old Issues

The following are previous model answers that apply to issues that are no longer being experienced, but may still be useful as inspiration.

Retrieved from "http://wiki.dreamwidth.net/wiki/index.php?title=Support_guide&oldid=12041"