So You Want to be a Support Volunteer

LiveJournal is a volunteer-friendly organization, and helping out in Support is a great way to learn more about how LiveJournal works. However, it is a time-consuming task that requires patience and professionalism. For many volunteers it will take weeks to earn that first approval.

However, if you're reading this, you're already off to a good start. The information in this document is designed to help you understand Support and get your answers approved. We'll do our best to answer your questions according to the FAQ below.

Please note that there is a lot of material you can read, both here and in the official communities. Don't feel as though you need to read through everything right now. If you're new to support and you're itching to jump in, just read the "Mechanics" section, and leave the rest for when you have more time.

This document last edited by [info]coffeechica on 4-May-07. Please contact support@livejournal.com to report any inaccuracies.


Table of Contents


MECHANICS

What are the absolute basics I need to know in order to get started?

First, feel free to jump right in! Support volunteers are a welcoming crowd, and you won't be causing a hindrance by leaving a screened answer. Trust what you know about LiveJournal, and trust what you've read in the FAQ.

Never contact users off of the Support board. Keeping all communication limited to the Support board ensures that users get the best possible answer, and we do not want users to feel harassed or stalked because of their Support requests. This includes leaving comments or sending emails for test purposes.

Do not copy other volunteers' answers, and don't copy the FAQ. If you want the user to read an FAQ to find the answer to their question, select that FAQ in the drop down box and direct the user to it, rather than copying what's in the FAQ.

If a request contains any private information or reports a security bug, leave it alone. Another volunteer will move it to a private category. Do not discuss or archive what you've seen; volunteers who are found discussing private information on the public board or using it for their own purposes may be banned from Support.

Please visit the following communities:

  • [info]lj_support - the main Support community where policies are announced. Reading this community is required for all support volunteers. Membership is restricted to those holding the supporthelp priv, but you can and should watch lj_support from your Friends page.
  • [info]learn_support - the community for new Support volunteers. Volunteers are encouraged to join learn_support and post questions about how they can improve their answers. This is a moderated community; please read the community guidelines carefully before posting.

If you notice mistakes in Support answers, or if you're concerned that you were passed over unfairly, email support@livejournal.com about it and the situation will be investigated by category admins.


How does Support work?

Users submit questions, which are then displayed on the board as green requests. As a new Support volunteer, your answers to these requests will be screened. This means that someone else with more experience in Support will read your answers over and only allow them to be sent to the users if they are correct and meet Support's guidelines. These guidelines will be explained in more depth later, in the policies section. Once an answer has been selected and sent to the user, the request will turn yellow.

Some internal information in Support requests will not be visible to you at first, most notably the screened responses of other volunteers. This means that sometimes you will answer a request that already has an acceptable answer recorded to it. The earlier answer will appear for you later, after it has been approved. This can be frustrating, but do not let it discourage you -- everyone experiences this at first. As a new volunteer you should focus on learning and practice, which can best be done by answering requests, even requests on which your answer is never approved. In time you will be able to see these responses.

Sometimes instead of an answer, a volunteer will make a comment. Comments are used primarily to request more information. Sometimes they are used to point out additional information that was left out of a previous answer, or to follow up on a request. Comments are not eligible for Support points. If you see a request that needs a comment, you can leave a screened response that you write as if it were a comment to the user. Support volunteers can approve screened responses as comments, and will do so when appropriate.

If it's an unusual request and you have information that shouldn't go through to the user but may be helpful to other volunteers, you can write it in a screened response with the words "INTERNAL COMMENT" all in capitals at the top. Internal comments should only be used if you have good reason to believe that the information you can provide is not common knowledge. In most cases experienced Support volunteers will know enough to handle requests.

After a request has been answered, the user may reply back with more questions. This is called a "regreen" because the request will go from yellow to green. These further questions must then be answered, but they do not have to be answered by the person who answered the first question. It's a good idea to check back on Support requests you have answered so that you can see what sort of answer was approved, and also to check for follow-up questions.

Once the user's questions have been answered, either the user will close the request or it will sit until one of the Support closers comes to close it. This may take a week, depending on the circumstances of the request. Once a request is closed, it will turn red, and will only be visible if you specifically ask the system to show you closed requests. Closed requests can be re-opened by users or by administrators if either believe that the original question was not completely answered. Under certain circumstances, administrators may also lock a request, which prevents the user from re-open ing it. Once a request has been closed for a few days, it will no longer be visible on the request board, although it will still be available at its direct URL.

Requests can be closed with credit to any approved answer in the request or without credit. Only one person can receive credit for each request, so support closers try to assign points fairly. The users may assign points, but they also may choose to close without credit.

The point value of a request is based upon the time the answer was submitted, not when the request is approved or closed. The minimum requests can be worth is one point, and the maximum they can be worth is ten points.

Once you have earned points, they will show on your full user info page, between the number of journal entries and the number of comments. You can also see your point total on the High Scores page. Points and rank are updated more or less instantaneously.


Why didn't my answer get approved?

Support takes patience and new volunteers should not expect to get approvals or points quickly. How long it takes will depend on what skills you have when entering Support, what you read, and how much effort you put into it. Keep in mind that only approved answers can earn points and that not every request closes with credit. For more details about how the Support system works check over the section about it.

One common reason for not getting approved is not being first. As a new volunteer, you can't see other answers. When an answer gets approved, compare the timestamp. If it is earlier than yours, then it was already there when you wrote your answer.

Another common reason for new volunteers not being approved is that their writing style doesn't meet Support standards. Support requires a very professional appearance. Things like emoticons (e.g. :)), "Hope this helps.", slang, poor spelling, and incomplete sentences can keep an accurate answer from being approved.

Another possibility is that the answer required more information. There are three issues that must be considered in every request. First, the user's explicit question must be addressed. Second, any misconceptions that the user has must be addressed. Finally, the answer must address any other issues the user needs to be informed of, but wouldn't have known enough to ask about. The best example of this is a user whose email address is not validated who asks an unrelated question. Validation must always be addressed when it comes up, as not being validated will lead to several problems for the user, such as being unable to post comments or resecure their account in the case of a break-in.

For more information on why your answers weren't approved, you can ask in [info]learn_support. Please review the community's guidelines before posting. You can also email support@livejournal.com if you want your question to only be seen by category admins, or if you're concerned about a possible error in the approved answer.


What are the policies I need to know about?

The most important rules of Support were presented above in the absolute basics section. This section goes into detail on more policies. The first rule of Support is that any policy might have an exception. Policies are there to improve how Support works, not bind us in cases where they don't fit. If you believe that an exception is needed in a specific case, you should contact the relevant category admins or email support@livejournal.com to ask about it. Sometimes exceptions will be made.

Support strives to be courteous, professional, and helpful. While some policies work toward more than one goal at a time, the policies divide up fairly well based on those concepts.

Courtesy

No matter what you think of a user's request, answer it with the respect you'd want if you had asked it. If you can't do that, do not touch the request in any way. You are always free to ignore requests that you dislike. Even in discussions outside the Support center, don't ridicule questions.

Be courteous toward other volunteers. If you have a question to ask, speak respectfully towards the volunteers who will be answering. If someone offends you, contact someone about it privately rather than starting a flamewar. Most problems are caused by misunderstandings that can be sorted out if everyone just discusses the issue calmly. Make corrections privately. Don't ridicule answers.

Specific policies:

  • Don't lie to users. There shouldn't be any situation that requires you to lie to a user. You can simplify, as many users do not need full details, but be honest.
  • Don't tell users to email other specific users unless it's about contacting a community's maintainer to deal with community issues. People do not like it when they are annoyed by someone and that person tells them Support told them to do so.
  • Do not include information that is completely irrelevant to the request. You can justify including instructions on using the lj-cut tag when explaining how to post pictures. But don't answer a how to validate question with: "And I noticed that your journal has really poor contrast and you can modify your colors by doing FOO."

Professionalism

Professionalism gives people a good impression of both LiveJournal and the Support team.

Specific policies:

  • Write clearly and concisely. All the standard rules of good writing apply to Support answers.
  • Don't use emoticons, slang, or idioms. These are not only unprofessional, but not all users will understand such expressions.
  • Be sure of your answer. Don't write something like, "Well, I'm not sure, but when my friend had a problem like this, blah blah blah worked..." The exception to this is when the request is very vague. Then you can say something like, "If you mean FOO, then you should do BAR. If you had something else in mind, please reply back so someone can help you further." Do not use phrases like "hope this helps" or "have a nice day".
  • Do not use the words "we" or "us". Support volunteers are rarely allowed to speak officially on behalf of LiveJournal. We do represent LiveJournal in the sense that we are what users see when they come to Support for help, but we do not make official decisions. Support volunteers do not control LiveJournal policies and should not give the impression that they can. In cases where you are talking about policy, rephrase the sentence by saying something like "the policy on this matter, which can be found over here, is...". If you feel the need to apologize to the user, do so on your own behalf by saying "I apologize for...".
  • Do not give support for things outside of the domain of LiveJournal. We can't support everything. If something falls outside the domain of LiveJournal, inform the user and try to give them a pointer of where to go, but do not recommend any specific sites. For example, with complex HTML, suggest they do a web search with their favorite search engine for "HTML tutorial" or similar phrases. Don't state the policies of third parties, such as Photobucket or Geocities. Send the user to investigate the other site's policies for themselves.
  • Whenever you link to a page that is not an official LiveJournal page, you should include a disclaimer that it is not affiliated with LiveJournal and LiveJournal cannot be held responsible for its content. This is important for many reasons. If the page changes, it makes it less likely users will complain. If the page has ads, it's important for users to know that those ads have no connection with LiveJournal and LiveJournal does not benefit from them in any way.
  • Don't sign your answers or use a greeting to begin them. Greetings and signatures are reserved for answers that are officially from LiveJournal, to make the distinction clearer. Your username and userpic are already associated with your answer when the request's page is viewed, so the user will be able to identify you as the person who tried to help them.
  • Keep default userpic, displayed name, or username appropriate for doing Support. LiveJournal has members of all ages, and as such the Support board should remain appropriate for young teenagers in terms of language and content. Also, the Support board is a politically neutral gathering place, so messages that are politically-charged should not be your support default. Other examples of inappropriate messages are those that undermine the purpose of Support, including demoralizing other volunteers or insulting the users. Any userpic with the keyword "_support" will override your journal's default userpic when you leave touches on the board, so this is a way that you can keep your preferred default icon and still have a Support-appropriate one associated with your touches.
  • Don't be a troll in official communities. If you are commenting in a community such as News or Suggestions and represent yourself as a Support volunteer, then your comment should be courteous and respectful, regardless of how others are speaking to you. We want support volunteers to have a site-wide reputation of being polite, helpful, and professional, as this relates to how willing a user is to see Support as being these things. Therefore, what you do when you are not representing yourself as a support volunteer is your own business, but please be aware that your behavior outside of Support may be taken into account when determining whether you are sufficiently trustworthy to be given privs.

Helpfulness

Helpfulness involves actually giving the user an answer they can use in response to their request.

Specific policies:

  • Always reference an FAQ when possible. When including a FAQ from the drop-down, you should mention why the FAQ was included, somewhere in the body of the answer. This can be a simple sentence like: "The above referenced FAQ explains how to validate your account." The importance of mentioning it is twofold. First, to make it clear to the user how the FAQ relates to their request. Often the relation is obvious, but in some requests it may not be apparent to the user, who may feel otherwise as though they received a response from a bot.

    The second reason is to ensure that the user knows there is a FAQ link that should be followed. Most users will read their answers in email, and the answer will embedded in some other text about the Support request. This can sometimes be confusing, and we want to make things as clear as possible.
  • Don't quote the FAQ. In general, just direct the user to the relevant portion of the FAQ. We want them to go to the FAQ, and they don't want to read the same information twice. If you feel that you must restate a piece of the FAQ for emphasis, make the selection as minimal as possible and rewrite it in your own words.
  • Be very careful whenever you tell a user to make a change involving things outside LiveJournal, such as turning on cookies or turning off email filters. Always either tell them to do it in a way that only affects LiveJournal or warn them about the possible downside to what they are doing. For example, in the case of filters, you may want to recommend they adjust them to allow livejournal.com emails through without affecting the rest of the filters.
  • Never tell a user to give their password to anyone. If the user brings up the idea, explain why that is a bad idea, and that Support will never ask for a user's password in order to provide help.
  • Answers must thoroughly answer the user's direct question, address any misconceptions the user has about LiveJournal, and address any obvious LiveJournal problems the user has.
  • Put your entire answer into one reply. We don't want to flood people with e-mails in reply to their support requests. If your incorrect answer is still a Screened Response, rewrite it completely and correctly and then submit it again. Please try to limit your resubmits to no more than 2, as this adds clutter to a request. If your answer was incorrect or incomplete, and it became an approved Answer, email support@ with a link to the request and a brief note that you were approved with a mistake that needs to be corrected. Don't worry that you made a mistake; nobody is perfect. Just do what you can to fix it.
  • If you are answering in a different language, provide internal translations. If you do not have the ability to make internal comments, leave your translation as a separate screened answer that starts with "INTERNAL COMMENT". Translate both the original request and your response, so that a supporthelp may understand your answer even if that supporthelp does not speak your language. The response to a request should be written in the same language it was made in whenever possible, unless the user specifically requests a response in another language.

Support is divided into categories, each of which is run by one or more category admins who can set policies for that category. Thus there are policies that apply in all public categories and policies that are category-specific. This Guide focuses on overall policies. The best way to learn category-specific rules is through [info]lj_support's memories and the communities for each specific categories.


TRAINING

How can I improve? What resources are available to me?

There are several things you can do to improve at Support. By reading this, you've already started. Another is to go through the memories for various Support communities. A good way to learn what to include in your answers is to look over approved answers. Don't copy them, but see how they're written and what sort of information they contain.

While answering requests, read them carefully and try to understand the user's point of view. What things might the user mean? If the user may be referring to multiple things, address them all. If the user asks multiple questions, answer them all. Think about what the user knows and what the user needs to know.

Read over your answer carefully. Is it well-written? Does the spacing make it easy to read? Does it include FAQ references when needed?

Learn the FAQs and check them every so often, since they do change. If you promise an answer is in an FAQ, read it yourself to make sure the answer will deliver on your promise.

Look over the information provided with the request. Is the account validated? Is the user free or paid? What style system are they using? What diagnostics were submitted with the support request? These things may have an effect on the answer.

Try to answer questions and check back to see what was approved. Look at requests you can't answer, and check back on them to see how they do get answered. Ask questions in [info]learn_support and get a review. After you have learned the basics of a category, you may wish to inquire about getting a mentor.


What are the official Support communities?

The main journal for Support is [info]lj_support, and the main journal for screened volunteers is [info]learn_support, both of which were explained earlier in this Guide.

Many Support categories have official communities. They are:

Some of these communities are intended for supporthelps only, and do not have public entries. The Issue Investigation category does not have a community to watch, as this is a diagnostic category used for investigation of certain types of requests from the entire board.

Other Official Support Communities:

  • [info]lj_supportadmin is the administrative community. Only category admins and LiveJournal staff have membership there. While any volunteer may watch it, and sometimes posts are made publicly, there is generally little there for non-members to see.
  • [info]support_interim is the community for those holding interim privs. When you earn interim privs, you should request membership; until then it is not worth watching.
  • [info]howto_userdoc is for the discussion of tutorials for inclusion in [info]howto and [info]s2howto. While it does not directly affect work on the Support Board, it is closely tied to Support and considered a part of the Support system.
  • [info]privchange is a journal where the addition and removal of Support privs is announced. Many volunteers watch this community so that they may be aware of -- and celebrate -- priv changes.
  • [info]howtosupport contains tutorials about writing Support answers and understanding various aspects of LiveJournal that frequently come up in Support.
  • [info]lj_userdoc is an official community focused on maintaining the FAQs.

This is not an exhaustive list; more official communities are listed in the FAQ. Feel free to explore these communities and watch the ones that are most interesting to you.


What does each Support category handle?

The following are the public Support categories: Clients, Communities, General/Unknown, Issue Investigation, Mobile Features, Scrapbook, Style Systems, Syndication, Userpics, and Web Interface. The private Support categories are: Abuse/AbuseLJ, Account Payments, Feedback, Privacy, Schools Directory, support@, and Webmaster.

The public categories are best understood by looking through relevant communities and Support community memories. The communities for each category are listed in the above section, and an explanation of who should read the community and how it should be used can be found in the userinfo of each community.

An explanation of the private categories and how they affect Support volunteers is below. If a request is opened in the wrong category and belongs in a private category, contact someone with the privs to move it. However, keep in mind that people with moving privs are around 24 hours a day, so most requests that belong in a private category are moved within a few minutes.

  • Abuse - the team that handles reported violations of the Terms of Service. All requests reporting specific journals for suspected abuse such as harassment or copyright violations, reports of journal break-ins, asking questions about suspended accounts, asking legal questions, or asking about the Terms of Service should be moved to the Abuse category. Abuse also handles reports that a user may be attempting suicide. For more information about the Abuse Team, see the userinfo of [info]lj_abuse.
  • Account Payments - handles problems with account payments. If a user didn't have a payment go through, or had a problem with how their payment was processed, it is handled by Accounts.
  • Feedback - is not currently being used, but might be used at some point to allow people to provide feedback to LiveJournal.
  • Privacy - handles questions about the LiveJournal privacy policy or concerns about LiveJournal sending out spam. These are rarely urgent and can sit until moved.
  • Schools Directory - manages the directory of schools that a user can choose on their userinfo.
  • Support@ - handles requests about Support itself. Emails sent to support@livejournal.com become support requests in the support@ category. You can use support@ to ask questions about Support that you don't know where to ask. Support@ should be contacted if you wish to leave Support and have your Support privs removed. Support@ also handles forwarding private requests when the category is unclear. If you have the ability to move requests and know a request should be private, but don't know where it should go, move it to support@ with an internal comment asking them to forward it. Support@ also handles requests that would be on the general board, except they contain personal information that must be kept private. Finally, support@ handles junk requests such as spam or nonsense.
  • Webmaster - requests about business issues, security holes, running bots, or the death of a LiveJournal user.

Some requests are unclear about whether they should be public or private. In these cases, always err on the side of privacy. A request can easily be moved back to the public board.

Also, with requests that should be private, it is even more important that you respect the privacy of the requesters, and you are expected not to discuss such requests at all. Do not post about them, even to get them moved, as this just causes more people to see them. If you are in IRC and see a request that needs to be moved, call attention to these requests via private message only.

For more information on each category, please consult the memories of [info]lj_support.


What's a review? Why should I get one?

Reviews are a wonderful way of learning how to improve your answers in Support. They involve an experienced volunteer looking over many requests you have recently tried to answer in a category and giving you feedback. It allows Support volunteers to get feedback that is more personalized to their needs, and it helps the category admins keep track of your progress.

Since Support is divided up into different categories, each run by its own category admin(s), reviews are generally done for one category at a time, and the process for reviewing may be different depending on the category. The [info]learn_support community contains more in-depth information about reviews; see its userinfo for the most relevant link.


Can I get a mentor?

There is no formal mentoring program at this time, but if you'd like to pair up with a mentor, email support@. Category admins may be able to match you with someone, if you don't have anyone in mind.

Having a mentor will give you someone to go to with questions. Your mentor will also likely review you, and may bring up issues for you to try to work on. You do not need a mentor to improve at Support, but some volunteers will feel more comfortable having someone specific they know that they can go to for advice and answers.


When should I report another volunteer? How do I do so?

Any volunteer may report anyone who they feel is violating Support policies, causing problems, or simply making mistakes. All reports should be sent to support@livejournal.com. Some volunteers are reluctant to report mistakes. Please keep in mind that a report does not mean that the volunteer in question will necessarily lose privs or have any other action taken. But mistakes need to be reported so that the volunteer can be corrected. Most reports will be handled simply with a reminder to the volunteer of the correct way to handle the situation. Warnings and removal of privs are usually reserved for people who continue to make the same mistakes after being informed of what they should be doing or who are behaving with deliberate malice.

Particularly good volunteers and Support requests handled particularly well should also be reported to admins, because admins enjoy sending notes of praise. These reports can also be sent to support@. AWE, Answered With Elegance, is another way to celebrate volunteer work on difficult or unique requests. AWE is posted irregularly, but the more links that are reported, the more often it can be posted. If you see work on a request that's suitable for an AWE nod, please see the userinfo of [info]supportlounge for information about who to email with the link.

Concerns about a category admin should be emailed to the Support Coordinator, as category admins are able to read anything emailed to support@. Concerns about the Support Coordinator can be emailed to the Customer Service Manager. The Support Coordinator at this time (April 2006) is [info]coffeechica and the Customer Service Manager is [info]denisep.


What should I do if I'm feeling stuck or burned out?

Feeling stuck or burned out often means that something needs to change. Talk to a category admin or a supporthelp that you trust. It may be that you need a break, or at least a fresh perspective on your work.

Some volunteers find that a change of pace helps them to get through difficult periods. If you're a specialist, try answering in a few different categories. If you're trying to get privs in all the categories, you may be attempting too much and focusing on one or two may help you feel like you're making more progress. Also, there are a variety of other volunteer opportunities on LiveJournal, and experimenting with the other opportunities that are available can provide you with the change of pace that you need to make your volunteering experience more interesting. You may even enjoy spending some time at another volunteer-driven organization, such as Wikipedia.

PRIVS

What are privs? What kinds of Support privs are available?

There are many privileges or "privs" associated with Support. A priv is what gives someone permission to take a particular action on a request. Most privs are publicly viewable at http://www.livejournal.com/admin/priv /.

Support volunteers will also refer to someone with the priv as a priv. So, the people with any of the interim Support privileges are collectively referred to as the interim privs.

Most Support privileges are given on a per category basis. Each priv has an "argument" after the priv itself, to designate in which category the priv is earned, e.g. "supportviewscreened:styles". Some people will have privileges in all categories. These are called unarged privs, because they have no argument after the priv.

There are nine support-related privs:

  • supportviewscreened - the ability to see other screened responses in requests
  • supportmakeinternal - the ability to make internal comments in requests
  • supportviewinternal - the ability to see internal comments in requests
  • supportmovetouch - the ability to change the category of a request and insert a request into or remove a request from the queue
  • supportchangesummary - the ability to change a request's summary
  • supportviewstocks - the ability to access a category's stock answer files
  • supporthelp - a combination of the five above privs, plus the ability to approve answers or comments
  • supportclose - the ability to close an open request, with or without credit
  • supportread - the ability to read requests that are in private categories

There are also admin privs that allow category admins to grant privs to others. Interim privs will be explained more fully in the following sections.


How do I get privs? What privs are given to each interim level?

Privs are granted at the discretion of category admins, and will be given to volunteers as they gain experience handling requests in a particular category. Most support categories require that you submit one or more reviews before you will be granted any privs. However, you should not expect privs to be given after every review. Your objectives should always be focused on learning how to improve your answers rather than on gaining specific privileges.

Interim level one (I1) consists of having supportviewscreened and supportmakeinternal. Interim level two (I2) consists of having those two plus supportviewinternal and supportmovetouch. A few categories offer supportviewinternal privs to those who reach I1. Interim level three (I3), previously called "priv-playing", consists of supportchangesummary and supportview stocks.

Supporthelp is the priv that allows a volunteer to approve screened responses as either answers or comments. It also allows the volunteer to submit an answer or comment directly, without the extra step of approving. Another function of the supporthelp priv is the ability to change the summary of a request (the text that appears on the Support board describing the request).

Supportclose allows a volunteer to close requests and assign points. This priv is generally reserved for Support administrators, but is occasionally granted to supporthelps.


What do I need to know as a new I1?

Using your new privs

I1 conveys two privileges, supportviewscreened and supportmakeinternal. A few categories offer supportviewinternal privs to those who reach I1. I1 makes Support a bit easier by allowing a volunteer to focus on requests that have not yet been adequately answered.

I1s are expected to keep screened responses confidential. They should not be discussing these screened responses in public or with anyone who is unable to view them. If they have questions about them, they can either email the category admin(s) for the category or bring them up in reviews, or with their mentor if applicable.

I1s are expected to use internal comments wisely. Non-supporthelps should not be commenting about shortcomings in other screened responses, what should be approved, or what needs to be in an approved answer. Only post ICs if there is something beyond the routine that you feel other volunteers need to know about. Some good examples of internal comment use would be linking to related requests by the same user, or linking to RT tickets that relate to the request. However, don't link to standard well-known resources, since most volunteers will already be aware of them and it will just add clutter. Do not leave an internal comment declaring that a request should be moved.

Internal comments are expected to be professional. Every time you leave an internal comment, you should be prepared for what you would tell the user if somehow it became visible. If you would not be able to handle that situation, you may want to re-think your comment. Internal comments are not to be used for irrelevant chatter or to talk about a user behind his/her back. When you reach I2, you may see some internal comments that are humorous. Privs are allowed to leave short off-topic comments in cases where an IC is automatically created, such as while moving or approving, but the content still must not be offensive.

Common issues at I1

I1s spend most of their time practicing writing according to support style.

I1s are expected to understand that not all screened responses are good models. If a screened response isn't approved, there may be a good reason for that. Some volunteers will find that other screened responses offer them a better perspective on how ambiguous requests may be interpreted or what information might be useful to include.

When you earn your first I1 priv, you should request to join [info]support_interim. This community is a good place to ask questions specific to using interim privs. There is also more information in memories about using your new privs.

And now that you can see screened answers, you might be tempted to provide feedback to others in the learn_support community, or email individual volunteers to correct them or ask them to change their answers. However, those are the sort of tasks that should be saved for people with supporthelp priv. Do not provide any feedback for other screened volunteers. While your answers are good, and you're clearly dedicated to the prospect of doing support and improving your answers, it's really easy for incorrect information to circulate through learn_support. Almost all the supporthelps watch learn_support, so someone will certainly be along within 24 hours to give a clear and correct answer. You are certainly welcome to post comments welcoming, supporting and encouraging those who are newer than yourself. Just hold back your specific advice about approval policies for now.


What do I need to know as a new I2?

Using your new privs

I2 conveys two new privileges, supportmovetouch and supportviewinternal (if the category did not already offer this as part of the I1 package).

If a request is in the wrong category, change the category first before doing anything else with the request. To change the category of a request, select "Internal Comment/Action" and the new category from the drop down. If the change is not obvious, add a brief note about why you are moving it, and then submit.

Before moving any requests, please review the What Goes Where post from lj_support. If you're unsure of where a request goes, don't move it. Wait for it to be moved by someone who is sure where it should go. Mishandled requests can result in unnecessary delays for the user, so we would rather have you ask than mismove in all cases that don't involve sensitive information. If you feel it is an urgent issue and needs to be moved off the public board, move it to support@ and an admin will redirect it if necessary.

You now have the ability to remove requests from the queue (degreen them). This is most often used when a user comments back with a 'Thanks!' to an answer they received, or in the case of duplicate requests. This type of comment needs no further action from us and should be degreened. However, use caution when degreening a request. Even if the user does not specifically ask another question, some types of user response may still need a follow-up answer. If a request is removed from the queue and still requires input, it could be days before an admin sees it again. If you are at all unsure about a degreen, leave it as is for another priv to deal with.

Common issues at I2

By the time you are given interim level two in a category, you probably have a great deal of Support experience and a good feel for how Support is done. Many volunteers will find themselves at I2 level for longer than they were unprivved or I1. This will vary from person to person, but it's a common occurrence. Try not to let it frustrate you. The step to supporthelp is a difficult one as mistakes made as a supporthelp can harm the users. As such, it is given out very carefully. We prefer to err on the side of caution.

Refrain from trying to train new volunteers. Training is left to supporthelps, to lessen the chance of people being given inaccurate information. While I2s tend to be very advanced and knowledgeable volunteers, they are still completing their own training and should focus their energy on that. If you don't think supporthelps have done an adequate job explaining something, or you see information that you feel is incorrect, email support@ and one of the admins will set things right.

You may see internal comments about things missing in Support answers or what is needed in an answer, but you should not make internal comments like this until you have the supporthelp priv.

Now that you're an I2, we'd like you to submit the more indepth review request format, as we find this can speed a person's progress through the I2 stage.


What do I need to know as a new I3?

Using your new privs

I3 conveys two new privileges: supportchangesummary and supportviewstocks.

You can change the summary to include special tags for how the request should be handled, such as indicating the user's preferred language or that a request needs admin attention. If a request's summary is not descriptive of the user's situation, you can change the summary to better describe the problem they are having. Try to use their own words whenever possible, and do not jump to conclusions. An incorrectly-changed summary might confuse privless volunteers or I1s who cannot see the original summary.

To change the summary, select "Internal Comment" and click the checkbox next to the summary. Enter the new summary in the text box. If you are adding more than just a processing tag, please add a slash (/) to indicate to volunteers unable to see ICs that the summary's text was changed.

You now have the ability to view stock answers for this category, but please be careful. All stocks must be tailored to the content of the request, to ensure that each user receives an answer that is most appropriate to their situation. Do not fall into the trap of scanning for keywords in a request and pasting a stock without a more careful reading of either the request or the answer. Stock answers marked with an asterisk (*) are absolutely not approvable without tailoring, so pay extra attention to these.

Priv-playing

The last stage of supporthelp training is priv-playing, though this may be skipped or altered depending on the category or the volunteer. If a category admin has awarded you I3 status, you may begin priv-playing at any time.

Priv-players are invited to leave ICs describing the action they would take if they were a supporthelp. Admins request that each priv-play IC be marked as such, and include the following information:

  • What information the request needs
  • What information, if anything, would make the answer better
  • Whether the priv-player would approve any of the existing screeneds on the answer
  • What other supporthelp actions the priv-player would take, if anything

What should I do if I want to leave Support?

Should you wish to stop volunteering, you can do so at any time. If you have privs, you should email support@ to alert admins to your absence, informing them if you intend to return. This is a courtesy to support admins, who wish to know who in their category should be considered as available and active. If you would like your privs to be removed, mention this as well.

If you go inactive for more than a month or two, you may find that your privs have been removed for you. This is not personal; it is simply because privs are given to people so that they can perform certain tasks. If you stop doing the tasks, you stop needing the privs. Each category has a different definition of who is active. Please consult your category admin(s) for more information about the category's inactivity policies.


What should I do if I want to return to Support after an absence?

If you wish to re-join Support after a long absence, you should again contact support@livejournal.com so that you can catch up as quickly and easily as possible. Please also read the applicable "Changes of Support" entries recorded in [info]lj_support's memories, as these are specifically designed to assist returning volunteers.

It is difficult to return to Support after an absence, and many volunteers get frustrated at having to be a screenie again, particularly if the volunteer once held supporthelp. Don't be discouraged. In most cases, interim privs can be awarded to returning supporthelps on the merit of past work in the category, so please do not hesitate to contact an admin for assistance if you're feeling frustrated.


SUPPORTHELPS

What do I need to know as a new supporthelp?

There are many aspects to being a supporthelp priv. The must fundamental task of a supporthelp is to answer and approve things on the board, but most supporthelps do much more than that.

Supporthelps do not have to handle any request they do not want to, even if they know how to, but if they do handle a request they must approve an acceptable screened response rather than writing their own if an acceptable one is already present. Supporthelps still have the options they had as a screened user and interim. You can still leave screened answers for others to approve. You may still ask questions in learn_support.

Supporthelps are also given membership and the ability to post in [info]lj_support. When you first gain supporthelp, you should look over the Support policy memories in [info]lj_support. Some of the entries about policies will be friends-only; please review these. The category might have more information for you in the memories of its official community.

Many supporthelps will do more than just work on the board. Supporthelps are welcome to become involved with reviews, mentoring, answering questions in the Support communities, spotting volunteers in need of reviews, bringing up issues for discussion, and reporting volunteers when necessary. To get involved in these activities, discuss it with the relevant category admins, who will direct you to the information you will need.

As a supporthelp priv you will be expected to serve as a good example to the other volunteers. While all volunteers are expected to be courteous and respectful, it is more strictly enforced on supporthelps. Other volunteers are considered to still be in training, and as such, mistakes are more understandable. However, we do not expect supporthelp privs to be perfect. It's perfectly fine if some mistakes happen. You may be informed of such mistakes by e-mail, but it doesn't mean anyone thinks you're a bad priv. It just means we want you to learn from it and improve. Mistakes of fact or policy are completely understandable, and in most cases are harmless in the grand scheme of things.

While we like all volunteers to follow up on the requests they try to answer, we especially encourage supporthelp privs to do so. A supporthelp can manage a request through its entire life-cycle. By following up on requests, you learn what information is most important to include, both for answers and internal comments. Supporthelps are not done learning simply because they've completed training. Some categories encourage post-SH reviews; contact your category admin(s) to see if you are eligible for one.


How do I approve an answer?

Deciding which answer to approve is not always easy, and there are no firm rules that will always work. However, this section provides some basic concepts to make it a little clearer.

Do not approve answers that violate any of the Support policies as explained earlier in this Guide.

Do not approve incoherent or poorly written answers, but in general a single typo is okay. If the typo causes the answer to be offensive or confusing, then that would make it unapprovable. If an average person would be able to figure out their problem given the content of the answer and the included links, this answer is approvable.

If an answer is close to approvable but not quite so, and the request is not urgent, it is encouraged for supporthelps to email the volunteer to improve the answer. It is never required to do so, but doing so helps the request get answered and the volunteer improve. It also increases volunteer morale, particularly if this is a request on which the volunteer has put forth considerable effort. If you do this, please IC on the request with a time limit under 24 hours that the volunteer has in order to resubmit their answer, before another volunteer may be approved instead.

Supporthelps are expected to approve the first approvable answer. However, if a user re-submits an answer with small improvements on their earlier approvable answer, many supporthelps choose to approve the re-submit as if it were the first answer on the request. This can mean that screened answers left in-between the re-submits may be passed over, but as the volunteer had the first approvable answer on the request, they would have been approved anyway.

It is good, but not required to leave explanations of why you approved what you did if it is not obvious. These notes are helpful both to I2s, so they can learn what the standards are, and to other supporthelps, so they can answer [info]learn_support and review questions more accurately.


When should I leave comments instead of answers?

Comments are used to ask questions or give additional information. However, if a request is ambiguous, it does not necessarily need a comment. Whenever it will be faster and simpler, an answer should simply address all possible interpretations. A supporthelp should comment requesting additional information only in those cases where the request does not contain sufficient information to resolve it.

Comments can also be used to correct mistakes. If the approved answer neglects to mention something important, a comment can add that information. Some supporthelps prefer to comment rather than answer if the user has already solved their problem, but this is up to the individual supporthelp.


What do I need to know about changing summaries?

Be sparing with changing summaries. When changing a summary, preface the change with a "/", to alert those who do not have viewinternal that the summary has been changed.

If a request has unusual circumstances but an unremarkable summary, changing the summary to something more descriptive can help make that request easier to find later, when researching requests of that type. Summaries may also be changed to add bracketed tags to denote language or the need for admin attention.


ADMINS

What are the duties of a category admin?

A category admin has the following responsibilities:

  • Making sure the requests in the category are answered promptly and correctly
  • Monitoring the training of volunteers in the category, providing encouragement and correction
  • Participating in policy discussion in [info]lj_supportadmin as well as in any other applicable communities
  • Managing privs in the category
  • Monitoring the documentation applicable to the category and proposing updates when necessary

This list is not exhaustive, and not all admins will have all of these responsibilities. Many categories have multiple admins to share these duties.


How are category admins selected?

Category admins are appointed rarely, usually when an existing admin decides to step down, but also in the case where category growth makes it difficult for the existing number of admins to keep up with the workload.

Each category admin is selected according to different criteria, depending on the needs of the category administration at that time. A supporthelp's unique talents will be taken into consideration, especially when balanced with the talents of the existing category admins. Sometimes admins will advertise in the category's community when there is an open position; other times the selection will take place without notice or consent of the supporthelps if there is no question about who is best fit for the position.

While the duties of category admins may differ according to the open position, all admin candidates are expected to have a history of being mature, available, friendly, and cooperative.


ODDITIES

Why did that request vanish?

Sometimes you will do something in a request, and then not be able to find that request again. It may vanish from both the open and closed requests. This generally means it was moved into a private category. Usually you won't get points for such requests, particularly in the case of Abuse requests, but every so often an answer given publicly will be used in support@. This means you can get points that you then can't find. Similarly, requests can appear on the public board already several hours or even days old if they were moved in from a private category.


Why are there two approved answers/comments on this request?

Some requests will have two answers about the same thing or two comments doing the same thing. This can be caused in two different ways. First, multiple Support answers and comments can happen because of technical problems just as multiple entries can. The other, and more common, reason is that two different people were trying to work on the request at the same time. The result is often called a "collision". To reduce the chance of collisions, supporthelp privs are encouraged to always post screened first and then approve.


Why does this user seem to be talking to himself?

Sometimes you'll see comments from the user who opened a request that look like half of a conversation. They may say something like "No, that's not the problem," or add additional information without the request having any approved responses from Support. Typically, these are requests opened by someone with support privs. They are replying to screened responses or internal comments that they can see.


What do the red and green numbers on the high scores page mean?

These numbers indicate a change in rank. This information is updated every Sunday.


SOCIAL ASPECTS

Does Support have an off-duty community? What about an IRC channel?

[info]supportlounge is the off-duty community. As with all communities, please read the community guidelines carefully before posting.

Many Support volunteers gather in #lj_support, an Internet Relay Chat (IRC) channel. (Instructions for connecting to IRC are included on the community profile page for .) This is an official channel operated by admins. It is an excellent way to contact supporthelps if you spot a request that needs to be moved, or if you want to help coordinate efforts to manage requests during site difficulties. However, #lj_support is an off-duty channel as much as it is a place for official activity, so the conversation is more akin to a workplace's cafeteria than a formal meeting place.

If you are looking for a room for real-time support training from on-duty supporthelps, please visit #backofthebook. #lj_support has a number of other spin-off channels, and any special events happening in other rooms will be mentioned in #lj_support's topic.


REFERENCE

What are some links that I can bookmark?

There are many links that you may find helpful, both for your own reference and to refer to in Support requests. However, before referencing any link in an answer, you should always check that the link currently works and contains the expected information. Some of these links aren't official and those links shouldn't be used in answers, but they are included because volunteers find them helpful. [info]bookmarklj is another good location for finding useful links.


Do you have a glossary to the commonly-used Support jargon?

Yes we do! If there's anything outside of this list that you do not understand, please don't hesitate to ask.

admin
Someone in an administrative role. The meaning of this word can be fuzzy. Sometimes people only refer to staff (employees of LiveJournal) as LiveJournal admins. Others refer to the category administrators as admins. Basically, it's just someone in an official leadership position, and the specifics vary.
approve
The act of turning a screened response into an answer or comment that the user will see. Privs approve answers and comments in requests.
AWE
Answered With Elegance - a posting of particularly well-answered requests in [info]supportlounge to share with all of the volunteers. AWE posts are made irregularly.
BAR
This is a variable, like FOO is. It is used to represent that something gets filled in where it is used. FOO and BAR are the most commonly used, although others you may see are BAZ, QUX, GIN, and TONIC.
Blinkie Ponie Armie
A term for volunteers in the Style System category. Blinkie is styles's mascot, created by [info]erin, and he has become a symbol for the hideous things that some users have done to their journals.
bastard freaky
An unusual request that can't be solved through the normal means and requires special attention and investigation.
b0rked
Broken, often spectacularly so.
bunny
Volunteers who prefer to work the top of the board and answer requests quickly are called bunnies, or "bunnehs". However, no matter where how old the request is, if someone sneaks in with an answer before you finish yours, you have been "bunnehed." The opposite of a bunny is a shark.
BYB
Big Yellow Box - the name for the known issues box. It used to be blue and was called the BBB, and when it changed to yellow some volunteers started calling it the "Big Bright Box".
canned answer
A saved answer to a common request that is reused. These need to be modified to fit the particular request if the request is somehow different. A good volunteer knows when to edit a canned answer.
category admin
Someone who oversees one of the Support categories. Category Admins are usually the best contacts for information about their categories.
cats
While Support volunteers will sometimes discuss felines, this usually is referring to the public Support categories. People will ask a question like, "What cat is it in?"
Client crashes in friends dialog
Thanks to its featured location on submit.bml, many users include this line as their summary, whether or not it has anything to do with their problem.
close fairy
This refers to anyone with the ability to close requests and assign points who has been actively closing the board. When closing has not been done in awhile, it causes volunteers to get a large increase in points in a short time. Some volunteers refer to these points as coming from the close fairy.
closing comments
This refers to going through requests and researching whether they are ready to be closed. Often internal comments are left pointing to evidence of the user having been helped. The name comes from before the ability to make summary changes, when all such requests needed comments to mark them as ready to be closed.
collision
When two supporthelps act at around the same time as each other, they can cause multiple comments/answers to go through. These are referred to as collisions. When multiple people comment answering the same question in a community, it is also referred to as a collision. Basically, a collision is any time that two or more people, by trying to be helpful, end up with a slightly less desirable effect.
comms
Short for communities. Usually used when referring to the communities Support category.
cust
Short for customization. Customization used to be a Support category, and was terminated in November 2002.
the dark side
Another name for the Communities category, nicknamed as such by Communities's first category admin [info]gooner. The "Hey Mickey" userpic was created by former admin [info]acerbic, who once declared "braaaanes and being a mindless zombie addicted to this song is what the dark side's all about".
degreening
The act of approving answers so that the requests turn from green to yellow.
FOO
This is a variable. For more information see BAR.
FrenchToast
Certain employees have the ability to grant privs in categories that do not exist. This means that, if you catch an employee in the proper state of silliness, privs can be granted for silly reasons. [info]leora was the first to receive supporthelp in a non-existent category; she held supporthelp in "FrenchToast" for years. Other classic privs of this sort include [info]remark who was granted supportmovetouch in "yourmom", and [info]coffeechica who was granted supporthelp in "coffee".
gunk
Slang for the General/Unknown category.
IANASH
I Am Not A SupportHelp. Used in [info]learn_support to explain why the person is only answering part of a question. Only supporthelp privs can answer specific questions about the answer required on requests.
IC
Internal Comment.
interim priv
Someone with some or all of the interim privs or a referral to one of the privs. Such as, FOO is now an interim priv, because she just got two interim privs.
manatee
Someone who is being mentored. Mentoree and manatee sound similar, so the more amusing form stuck.
mongoose
A comment often made when a volunteer has no opinion one way or another on a decision. Many volunteers have adopted mongeese userpics for such occasions.
no pony
An answer that informs the user their request is outside the realm of Support, but usually only when it is absurdly so. Most often used in Styles, in the cases where some users demand a long and complex list of customizations that volunteers should do for them, and the joke is "and I also want a pony". Oddly enough, this means most "no pony" answers are provided by members of the Blinkie Ponie Armie. You may also see this referred to as "!pony".
NOP
Abbreviation for "Not Our Problem". NOP requests include everything outside the realm of Support, such as Google's listings, using an AIM profile, or the user who wants to know why their monitor has white-out on it.
PAF/Paid Account Fairy
Sometimes long-time support volunteers find that they unexpectedly have more paid time than they used to, or suddenly have a paid account. The Paid Account Fairy lurks around the edges of the support board, looking for people to gift with paid time.
regreen
When a user comments back to a request, it turns back from yellow to green, so it is called a regreen.
RT
LiveJournal's bug tracking system. This is where bugs are reported and proposed improvements are worked on. An RT ticket refers to a specific LiveJournal bug or enhancement. RT is located at http://rt.livejournal.org.
screened
Refers to answers or comments that cannot yet be seen by the user. "Screened people" can also be used to refer to volunteers with no supporthelps privs.
shark
Volunteers who prefer to work the older requests near the bottom of the board are called sharks. This is because the older requests often require a more patient, predatory mindset.
shiny
A compliment, usually in regards to someone else's answer. The goal of a volunteer is to write shiny answers rather than those that are simply approvable. You may hear people discussing what is required in an answer, as opposed to what's considered shiny.
spr0t
A nickname for "support" invented by [info]kamara one day in #lj_support when she was doing an impression of a user wanting to speak to a supporthelp: "OMG I DUN LIKE THAT ANSWAH I WANNA SPEEK TO A SPR0THEPL!!1111" After that, spr0thepl! and spr0t helped spawn [info]omg_a_surprise, a one-time use journal to celebrate someone's privs.
validation nag
The automatic text that appears in the box when a user is not validated. Can be shortened to "valnag" or "autonag".
whomp
Refers to handling users who need to be told that they are somehow taking advantage of the Support system. Repeat abusers are said to be whomped. The whomping is traditionally done with a whompy thing. When large numbers of requests are handled in a small span of time, they may also be said to be whomped regardless of what kind of requests they are.
YARTINE
Yet Another Request That Is Not Embedding. When Embedding was a support category, requests were frequently opened there that had nothing to do with embedding a journal into a website. To complicate matters, at one time there were few volunteers with moving privs in Embedding, so YARTINE requests were often frustrating for bunny-style volunteers to encounter.
YASC
Yet Another Support Community. There are rather a lot and when new ones are made people will sometimes use this acronym.
Create an Account
Forgot your login?
Login w/ OpenID
English • Español • Deutsch • Русский…