Difference between revisions of "Support process"

Revision as of 16:55, 6 May 2013

This page reviews how the support board works, how to respond to requests (focusing on the technical side), what certain privileges allow one to do, and so forth.

For policies on how to handle specific types of support requests, see Support guide.

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, and is slowly getting updated to reflect how objects have settled during flight. 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 confusion. (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.

1. ID#: This is the internal number for the request. (Clicking the number is the only way to access the actual request.)
2. Summary: This is the summary provided by the user at the time the user opened the request.
   • Earlier summaries started with [xx], due to code that hadn't yet been removed from what was inherited from LJ.
   • Sometimes someone with the appropriate privileges ("privs") will change the summary, if they think that the summary is insufficiently descriptive.
3. 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 current public categories are:

• General/Unknown
• Communities
• Entries
• Styles
• Site Interface
• Feeds
• Importer
• Crossposting
• OpenID

The current private categories are Account Payments, Feedback, Anti-Spam, and Terms of Service. (Peterstein and Webmaster also exist.)

Request categories can be changed by someone with the supportmovetouch or supporthelp privs. See What Goes Where for more on the sorting of support requests.

1. Posted: The time that the request was submitted. This is in relative time.
2. Status: Requests can be in one of four statuses. See below for more information.

This table can be sorted by ID#, Summary, or Problem Area, by clicking on the column headers.

Statuses

Requests can have one of four statuses.

1. Open ("green", with a green background in the table row): 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.
2. Answered, Awaiting Close ("yellow" or "AAC", with a yellow/beige background in the table row): An answer has been sent to the user, but the user hasn't confirmed that, or whether, 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.
3. 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 has indicated that the provided answer doesn't fully answer their question.
4. Closed (with a pink background in the table row): The user or an administrator has closed the request. Both users and administrators can reopen a closed request if further contact is needed.

Filtering the board

You can filter the board in three ways: by category, by status, or by category and status.

The filters are:

• "Open": This shows all requests that are "Open", "Answered, Still Needs Help", or "Answered, Awaiting Close", as described above.

• "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" and "Answered, Still Needs Help".

• "You Replied": This option is only available 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

There are several components to a support request.

Account information

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.)

Support description

Next in the request 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.

(For advice on how to reply to users, see the Support guide.)

Support instructions

Underneath the user-provided summary is a box containing instructions for support volunteers:

Important Notes:

Dreamwidth Support is an open-source project run by a community of volunteers. If you think you know the answer to this question, you're welcome to submit an answer in the box below. Your answer will be screened and evaluated by senior support volunteers for content. If your answer is first and correct, it will be sent to the person who submitted the question.

If you have questions about Support, please read the Support Wiki category for more information.

Thank you!

Response box

At the very bottom is a place where you can submit your response to the user.

The first thing you see is 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.

Next is the reply type, which is explained in detail in the next section.

Finally, 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, use an Internal Comment if you can. If you cannot, 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 *****". (This shouldn't be too much of an issue, since anyone who wants to volunteer in Support for Dreamwidth can have the supportmakeinternal privs on request, which will allow them to make actual internal comments instead of leaving notes as screened responses. But if you don't have those privs for some reason, make sure you clearly mark any internal notes.)

• 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. If you do not have the privs to leave an Internal Comment, leave a clearly marked Screened Response as described above.

Responses cannot be edited. Double-check your response before submitting. If you find that something must be changed, make a second response. Screened Responses that are intended to become Answers should not mention the first draft, as the user will likely not be able to see the first Screened Response.

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. Closing runs happen periodically in accordance with the administrators' schedules.

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 is also an IRC channel for real-time chat.

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.

Spam on the board

Sometimes, spam makes its way through to the support board. The board is monitored fairly regularly, so if you see spam on the board, just let it slide; it will likely be removed soon.

The people who can deal with spam on the board are those who have the privs to move a request out of its current category, rather than the antispam team (who deal with comment, private message, and community entry spam reports).

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 taken as attacking or criticizing another site or service's support team.

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, expect 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.