Difference between revisions of "Support process"

Revision as of 04:47, 30 April 2009

The Support Board

The support board on Dreamwidth can be found at Support Requests. It's also known as "the board" or "the support board". You'll usually hear "the board", for the most part.

This is a braindump of the basics of the support board. How things apply on Dreamwidth itself is going to be in flux for the first few weeks, as we decide what our policies will be. Please bear with us! Things will be chaos and confusion, but we're very grateful for anyone who wants to spend time volunteering in support.

Types of User Contacts

The support board tends to get a few distinct types of user contacts:

• Someone needs to know how to do something on Dreamwidth, or has a question about whether or not something's possible. These requests are often handled with a reference to a FAQ; sometimes, they require more in-depth tutorials or instructions.

• Someone is having a technical problem that they need help diagnosing and resolving. Sometimes this is a bug with the system itself; sometimes it's just that the user doesn't know how to use the functionality as provided; sometimes it's a glitch in their browser; sometimes it doesn't actually do what they think it does; sometimes it's a combination of all of the above. These requests tend to need multiple contacts to properly diagnose it, and it's likely that you'll need to start at the basics to rule out user error or misconfusion. (See the Support guide for some style tips on how to do that most effectively.

• Someone needs to get in touch with the site administrators (mark and denise) for whatever reason -- partnership opportunity, press inquiry, questions about Dreamwidth Studios the business, or questions or feedback on a Dreamwidth Studios action or policy. These should be transfered to the Feedback category.

• Someone needs to report violations of the Terms of Service, or has questions about how the Terms of Service are enforced. These should be transfered to the Terms of Service category.

Unfortunately, there's no way to separate out these types of requests, since the categories are divided by area of the site and not by type of request. (Also, many requests will span types.) Keep in mind as you view the support board, though, that something that looks simple may turn out to be complex, and something that looks complex may turn out to be simple.

Explaining the Board

When you first load the board, you'll see a table that has five columns: ID#, Summary, Problem Area, Posted, and Status.

• ID #: This is the internal number for the request. (Clicking the number is the only way to access the actual request.)

• Summary: This is the summary provided by the user at the time the user opened the request. They all start with [xx] because of code we haven't removed from what we inherited from LJ yet. Sometimes someone with the appropriate Privileges ("privs") will change the summary, if they think that the summary is insufficiently descriptive.

• Problem Area: This is the request's category. There are public and private categories, and support privileges can be handed out by category, so it's possible to have privs in one category but not another. The public categories we have right now are: Communities, Entries, General/Unknown, Importer, Site Interface, and Styles. The private categories we have are Account Payments, Feedback, and Terms of Service. Request categories can be changed by someone with the supportmovetouch or supporthelp privs.

• Posted: The time that the request was submitted. This is in relative time.

• Status: Requests can be in one of four statuses. See below for more information.

Statuses

Requests can be in one of four statuses:

• Open ("green", with a green background in the table row); this means that an answer has not yet been sent to the user. Requests that are opened may or may not have screened answers (see below) waiting on them. If you don't have the supportviewscreened priv, you won't be able to tell.

• Answered, Awaiting Close ("yellow" or "AAC", with a yellow/beige background in the table row); this means an answer has been sent to the user, but the user hasn't confirmed that it helped. Requests will stay in the "answered, awaiting close" status until either the user or the administrator closes it; they are never auto-closed.

• Answered, Still Needs Help ("regreen" or "SNH", with a green background to the table row); an answer has been sent to the user but the user's indicated that the provided answer doesn't fully answer their question.

• Closed (with a pink background in the table row), where the user or an administrator has closed the request -- both users and adminstrators can reopen a closed request if further contact is needed.

Filtering the board

You can filter the board in two ways: by category or by status. You can also filter by category and status.

The filters are:

• "Open" -- This shows all requests that are Open (have no answer); Answered, Still Needs Help (answered, but user has indicated they still have more concerns/questions); or Answered, Awaiting Close (user has received an answer, but has not yet closed the request).

• "Closed" -- This shows all requests that have been closed (by the user or by an administrator) in the past 24 hours. After 24 hours, the request drops off this filter, and you'll need to know the request ID number (or have access to one of the administrative tools to look it up), so if you want to save a request for later study, bookmark it.

• "Green" -- This shows all requests that are Open (have no answer) and Answered, Still Needs Help.

• "You Replied" -- This only shows if you're logged in. This filter will show you every request you've touched -- answer, screened response, internal comment or action, anything -- from the union of all three above filters. (In other words: any request that's open, answered, still needs help, or was closed in the past 24 hours.) Requests will appear in this filter even if your screened response wasn't the approved one.

Inside a Request

When you open up a request, the top of the request contains information about the user's account. This includes information about their settings, such as what database cluster their account is stored on (which can be useful in diagnosing technical problems -- if everyone who's having a problem that you can't reproduce on your account is on a single cluster, that's a sign you should poke mark) and what site scheme they've chosen (which can help you diagnose display problems). (We'll be providing guides to diagnosis and investigation as soon as we can.)

Underneath the diagnostic information is the user-provided description of the request. Sometimes users will ask questions; sometimes they'll report problems. Read the request carefully! Sometimes users don't know what they're asking to do, or are confused about what they're trying to do. If you spot something that makes you think that the user might be confused, be sure to straighten out the confusion in your answer.

Underneath the user-provided summary is a box containing instructions. We haven't rewritten that text to be Dreamwidth-specific yet -- we're holding off on doing that until we know a little more about how our support volunteer process will work. (We'll be building that over the first few weeks of operations as we see what works and what doesn't.)

Finally, underneath all of that, there's a place where you can submit your response to the user. There's a drop-down containing all of the FAQs. If there's a FAQ that's appropriate for the user's question, you can select in the drop-down; the email sent to the user notifying them of your response will include the FAQ reference, and if they view the request on the web, it'll be included there, too. If you select a FAQ in the drop-down box, be sure to mention that you have, in the body of your answer -- sometimes people can overlook it. Something as simple as "I've included a reference to a FAQ that may have more information about your problem", or however you want to phrase it, is good enough.

Type your answer itself into the box marked "Message". Be sure that your answer conforms to the style as described in the Support guide. In particular, you should address the user ("Dear so-and-so", or "Hi, so-and-so", or some form of greeting, whatever you prefer) and sign your name (any name you'd like to give -- your username, your actual name, your nickname, it doesn't matter, just be consistent).

Once you've written a response, hit "Post Comment/Solution", and your answer will be submitted to the request. It will not be visible to the user at first. (See below.) You'll be able to see it, but the user won't be able to see it yet. This is to make sure that the user gets the best, most accurate answer possible.

If you can't answer the user's whole request, or don't know the answer to all of their questions, leave the request alone and move on. We won't approve partial answers -- it's better for the user to get one email, rather than four or five.

Four types of responses

There are four types of responses that can be added to a request:

• Screened Response. This is the default. If you don't have any privs at all, all you can do is leave a screened response. These are visible only to the person who posted to them, and to anyone who has the supportviewscreened or supporthelp privs. This response type has a yellow border on the request, and will be labeled "Screened Response". Always assume, if you're leaving a screened response, that it may be approved. If you need to leave some sort of internal note, make sure you indicate at the top of your response, in capital letters and with some sort of standout, that it's an internal note: something like "***** INTERNAL NOTE *****".

• Answer. This happens once a screened response has been approved by someone with the supporthelp priv. When a response is approved as an answer, an email is sent to the user, the request status goes from "Open" to "Answered, Awaiting Close", the response type changes from "Screened Response" to "Answer", the response is made visible to anyone who views the request, and the border of the response changes from yellow to green. People with the supporthelp priv can approve other people's screened responses or their own. (They also have the ability to answer directly without going through the screened response first; however, this isn't a good idea. If you have supporthelp, always answer screened and then approve yourself. The typos never show until you read over the response the second time.)

• Comment. This happens once a screened response has been approved as a comment by someone with the supporthelp priv. When a response is approved as a comment, an email is sent to the user, the response type changes from "Screened Response" to "Comment", the response is made visible to anyone who views the request, and the border of the response changes from yellow to black. The request status does not change. It's used to prompt the user for more information, or ask some diagnostic questions.

• Internal comment ("IC"). This is a response that cannot accidentally be sent to the user: it will always remain internal-only. An internal comment can only be made by someone who holds the supportmakeinternal or supporthelp privs, and will not be visible to anyone but someone who holds the supportviewinternal or supporthelp privs. They're generally used to swap theories about complicated requests or include troubleshooting notes or information.

Life cycle of a request

1. User opens a request at the Submit page.

2. If the request is in the wrong category, someone with the supportmovetouch or supporthelp privs will send it to the right category. (If you have these privs, this should be the first thing you check.)

3. If the summary is bad or misleading, someone with the supportchangesummary or supporthelp privs will change the summary to something more accurate. (If you have these privs, this should be the second thing you check.)

4. If you know the answer to the request, you can leave a Screened Response. You may not be approved. (See below.)

5. Someone with supporthelp will evaluate all of the Screened Responses on the request, and select the one, in their opinion, that best answers the user's question. They'll approve that Screened Response as an answer. If (in their opinion) none of the responses available answer the user's question entirely, they have the option to write their own answer and approve it.

6. The user will get the response email, and have a chance to return to the request and ask further questions or indicate that their question was answered and they don't need to ask any more questions. Sometimes they do neither, and the request will just sit there.

7. If the user doesn't close the request, sooner or later an administrator with the supportclose priv will come along and close it. This also serves as an additional qualitycheck.

8. If the user does indicate that they need more help, anyone can submit a followup answer. It doesn't have to be by the person who originally answered the request -- if you have the answer, feel free to leave it. This will bring us back to step 5, and the process continues.

Why your screened response might not have been approved

If you don't have the supportviewscreened and supportviewinternal privs, it's hard to tell why your response wasn't approved. We're going to be granting those privs to anyone who wants them, but if you don't know about them, you can still wind up getting confused. Until we can put a better training system into place, we'll be using dw_support_training to coordinate people who are just starting out in support, and dw_support for people who have the higher-level support privs (supporthelp and support administrative privs).

There are a number of reasons why your screened response might not have been approved. This includes:

1. Someone with the supporthelp priv might not have gotten the chance to evaluate the request yet. This is the case if there isn't an approved answer on the request -- if nothing has been approved on the answer yet, it could mean that there's something wrong with all the answers, but it's also possible that nobody's looked at it yet.

2. Someone may have submitted an approvable answer earlier than you did. If the approved answer appears before your screened response, it means that it was submitted earlier than yours, and the supporthelp who approved the answer felt that the earlier answer contained everything the user needed.

3. You may have had an error in form. Failure to greet the user or sign your request, any major spelling/typo/grammar issues, or other matters of style (see the [Support guide]) may cause someone to decide against approving you.

4. You may have had incomplete information. Compare your answer against the approved answer and see what it has that your answer doesn't.

5. You may have gotten your answer completely right, but the approved answer comes after yours -- in this case, it's possible that the person whose answer was approved had an earlier answer, then you submitted yours, then they re-submitted theirs to correct a typo or expand on some finer points. Because there's no way to edit a support response, edits show up as a newer screened response, posted later. (If you do have supportviewscreened, you can verify this.)

If you absolutely can't figure out why your screened response wasn't accepted, you can post to dw_support_training with a link to the request, asking why you weren't approved. Please don't critique the actual approved answer. If you think a response was approved incorrectly, privately contact denise.

Privs on Dreamwidth

Anyone who's interested in volunteering for Dreamwidth support will be granted the supportviewscreened and supportmakeinternal privs. Right now, the way to get these privs is to comment to this entry in dw_support_training. After you do, denise will grant you the appropriate privs (as soon as she gets a spare second!)

For information on who has the supporthelp priv, you can see the Dreamwidth supporthelp list.

For a full rundown on what privs do what, how they work, and what bits of the support board they affect, see Privileges.

Right now, we're not yet certain what our criteria will be for handing out support privs other than supportviewscreened and supportmakeinternal. For the first few weeks of Dreamwidth's operation, it'll likely be a very freeform sort of system where people who are answering regularly and correctly will get more privs as they demonstrate their commitment.

We've decided against offering any form of reciprocal privs -- even if you have support privs on another LJ-based site, you won't automatically get those privs on Dreamwidth. This is partially because our support style is drastically different from other sites, and partially so that everyone starts from an equal playing field.

Feedback on the support process

We do absolutely want to hear your ideas and thoughts about how things should run. One thing to keep in mind, however, is that when you're providing feedback about the support process, support policies, support training, and the support system, or expressing your thoughts on how Dreamwidth support should run, it is absolutely critical that you keep your suggestions positive: what we can do, rather than comparing Dreamwidth support to any other service's or site's support team, support offerings, or support procedures.

It's okay to talk about general lessons you've learned elsewhere or on other sites, but please avoid talking about bad experiences you had elsewhere (whether as a customer or as a member of a site support team), avoid making comparisons between Dreamwidth's support and any other site or service's support, and avoid any language that could be taking as attacking or critiquing another site or service's support.

Everyone is welcome to volunteer for Dreamwidth support! While it might look complex, in practice the system does function fairly effectively. Things are going to be chaotic for the first few weeks as we work out the best practices -- how we can use the technical tools available to us in the most efficient fashion -- to provide kickass customer service.

Over the next few weeks, look for tutorials on how to investigate and diagnose a problem, how to best deal with users who have problems that could be one of many different things, how to keep track of known issues (and how to report issues as they come up), and how to communicate effectively with users.