Guide Part I
Here's a much more finished version.
SuportOffice is down, but I just left the text as if it isn't. And my definition list in part II keeps being broken, but I have no clue why. If anyone can figure it out, that'd be neat.
Anyhow the LiveJournal Support Guide in progress:
So You Want to be a Support Volunteer
Table of Contents
Introduction
Basic Support Rules
How Support Works
Support Rules in More Detail
Support Communities
Why Answers Don't Get Approved
How to Improve at Support
Reviews
Mentoring
Support Privs
Understanding the Categories
Interim Level One
Interim Level Two
Summary Tags
Being a Supporthelp Priv
Leaving Comments
Approving Answers
Reporting Volunteers
Leaving Support
Support Oddities
Social Aspects of Support
Useful Links
Glossary of Support Terms
Introduction
LiveJournal can always use more volunteers 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. Don't expect to just jump in answering questions and get a bunch of points. For many volunteers it will take weeks to earn their first support point.
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. Some other good resources are the following communities:
lj_support - the main Support community where policies are announced. New volunteers cannot join, but they can and should friend it. Reading lj_support is required for all support
volunteers.
helpscreening - the community for new Support volunteers. Volunteers are encouraged to join and post questions here. The guidelines for HelpScreening are linked to from its userinfo. Both of the above communities have particularly helpful posts
saved as memories. Reading through the memories is a very good way to learn more.
Please note that there is a lot of material you can read, and reading it will almost surely help you do better in Support. But don't feel as if you need to read through everything right now. It's generally best to take things at your own pace. Start with the first three sections of this guide, and then read the rest as you feel ready to learn more.
This guide is designed to answer most of the common questions Support volunteers at all different experience levels have. While reading the sections for more experienced volunteers is fine, there is no reason to feel you should. This is a very long document, and is meant to be read in small pieces as you progress in Support.
Basic Support Rules
There are many Support policies, but only a few that are really important to keep in mind when you're just starting out. For a more detailed listing of support policies, check out the Support communities and later parts of this Guide.
Never contact users off of the Support board. If there is a reason why it is important to do so, then someone who is authorized to do so will. We do not want users to feel harassed or stalked because of their Support requests.
Treat people with respect. This goes for both the people who submit requests and your fellow volunteers. Do not make fun of people who submit Support requests. If you have a question to ask, ask it politely. 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. If you notice mistakes in Support answers, email support@livejournal.com about it and it will be forwarded to the appropriate person or people.
Do not copy other volunteers' answers. You can use other people's answers as a guide to what content yours should include, but write your own answers. If you need help with the wording, ask in HelpScreening.
If a request contains any private information or reports a security bug, do not discuss the request with anyone. As you become more experienced with Support, you will learn how to handle these requests, but until you do, it's simplest to just keep quiet about them. Volunteers who are found discussing private information on the board or using it for their own purposes may be banned from Support.
How Support Works
Users submit Support requests that are then opened on the board as green requests. They remain green until an answer is approved, and then they turn yellow. If they re-open because the user needs more help, they will turn green again until re-answered and say "answered still needs help". When a request closes it will be moved to the closed section and be a pinkish red. Eventually it will disappear entirely, but still be findable by the specific URL to the request. The exact colors may vary from system to system.
As a new Support volunteer your answers will be screened. This means that someone with more experience in Support will read them over and only allow them to be sent to the users if they meet Support's guidelines. There are several Support guidelines both for the board as a whole and category-specific. These will be explained in more depth later.
There are many forms of information in Support requests that you will not be able to see at first. The most notable are other volunteers' screened answers. This means that sometimes you will answer a question that already has an acceptable answer in it. Don't let this discourage you. As a new volunteer you should focus on learning as much as you can. In time you will be able to see these answers.
Sometimes instead of an answer, a comment will be made. 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 followup on a request. Comments can never earn Support points.
If you see a comment in a request asking for more information, you should not attempt to answer the request until the user has replied back. While sometimes an answer will be approved before then, especially if the user seems unwilling to reply back, most of the time attempting to answer such questions will just be a waste of effort.
If you see a request that needs a comment, you can leave a screened answer intended to go through as a comment to the user. Support volunteers can approve screened answers 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 Support, you can leave a message to the other volunteers. Leave a screened answer with the words "INTERNAL COMMENT" all in caps with the information. This will help volunteers to resolve the request. These screened answers can also never earn points, but they do help to get requests resolved. Internal comments should only be used if you have good reason to suspect that the information you can provide is unusual. 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. These further questions must then be answered, but not necessarily by the person who answered the first question. It's a good idea to check back on Support requests you have answered both to see what sort of answer was approvable and to check for followup questions. Once the user is fully helped either the user will close the request or it will sit until one of the Support closers comes to close it.
Requests, regardless of who closes them, can be closed with credit to any answer in the request or without credit. Support closers will attempt to assign credit fairly, but only one person can receive credit for each request. The users may assign points fairly, but they also may close without credit. This is just a natural part of Support. Not all requests are expected to yield points for anyone.
Most requests will take about a week to close. Many will take longer if they require users to comment back, second answers, or new problems. These too will eventually close, but later.
Closed requests can also be re-opened by users. This does not happen often, but when it does the points will be revoked. They may then be re-assigned when the request closes again.
The value of a request is based upon the time the answer/screened answer was submitted. The value of that answer, if the request is closed to it, will be the amount showing at that time, regardless of when it is approved or closed. Most requests are worth one or two points, and the maximum they can be worth is ten points.
Once you have earned points, they will show on your full user info page. You can also see both your points and how it compares to every Support volunteer who has ever earned points at the High Scores page. On that page there will be little numbers in red or green next to many of the scores. This is how much their rank has changed since the last time it was calculated. Points and rank are updated more or less instantaneously. Change in rank is usually updated weekly, but sometimes problems happen and changes in rank will freeze and not be updated for a while.
You can find the specific requests which earned you points in public categories through use of the Support Office. This is not an official LiveJournal tool, but is very useful for Support volunteers. It can do more than just find where you earned points. It is located at http://supportoffice.callete.com/.
Support Rules in More Detail
Support is divided into categories. Each category is run by one or more category admins who can set policies for that category. Thus there are both rules that apply in all public categories and rules that are category-specific. This Guide focuses on overall rules. The best way to learn category-specific rules is through lj_support's memories and the communities for the categories and through the communities for specific categories.
The first rule of Support is that any policy might have an exception if a good enough reason comes up. 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.
The most important rules of Support were presented in the section What rules do I need to follow?. This section goes into detail on more policies. If there is ever a conflict between this guide and information given in official Support communities, then the communities take
precedence. This guide cannot be constantly updated, and the communities can deal with issues as they occur.
There are some exceptions to the rules in the short rules section. Answer copying is allowed with the permission of the person who wrote the original answer, but is highly discouraged for most volunteers anyway. Answer copying makes it harder to learn how to do Support, and thus is generally only used by those who have enough experience already to not need more work on answer writing. Reusing your own answers is perfectly acceptable so long as you modify them to fit the specific request you are answering.
Contacting users off the board is rarely allowed, but if a user writes a thank you post in their journal, you may comment politely to it. If the user friends you, you may then comment to them or friend them if you wish.
Support strives to be courteous, professional, and helpful. While some rules work toward more than one of those, the rules divide up fairly well based on those concepts. This section also explores what those ideas mean.
Courtesy
Courtesy is fairly simple. 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. Learn from answers by other volunteers (when you can tell that they're right), but don't just copy them word for word. If you feel compelled to complain about a common mistake, criticize the mistake, not the individuals who made it. Make corrections privately. Don't ridicule answers.
Specific rules:
Professionalism
Professionalism gives people a good impression of both LiveJournal and the Support team. You are expected to act professionally in all Support-related contexts. If you are commenting in an official community and represent yourself as a Support volunteer, then your comment should be professional
and courteous. However, when you are outside Support contexts, your actions may be whatever you wish.
Specific rules:
Helpfulness
Helpfulness involves actually giving the user an answer they can use in response to their request. The entire point of Support is to help people. We want to do it kindly and without offense, but we need to make sure that we help them.
Specific rules:
Support Communities
The main journal for Support is lj_support. Every Support volunteer should read it. Official policies are announced there and relevant LiveJournal news is relayed there. Sometimes the direction that LiveJournal Support should take is discussed there. Any volunteer may read it, but only experienced volunteers are granted posting access. Posting access and membership is given when a volunteer earns supporthelp priv in any category of Support.
The next community to consider is helpscreening. This community is open to all volunteers. It is used to give tips on how to better answer in Support and to ask Support-related questions.
All of the public Support categories have communities. They
are:
support_clients, support_comms, support_embed, support_general, support_ssystem, support_syn, support_upi, support_web, and web_ui. Information about them can be found in the userinfo for each community.
Other Support Communities:
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, for the most part there is little worth seeing there for non-members.
support_interim is the community for interim privs. When you earn interim privs, you will be added, until then it is not worth watching.
supportlounge is an unofficial community where many Support volunteers post about their Support experience, amusing Support related events, or share particularly impressive requests.
howto_userdoc is an official community for the discussion of tutorials for inclusion in howto. While not a part of the Support Board, it is closely tied to Support and considered a part of the Support system.
privchange is a journal where the addition and removal of Support privs is announced. No one is required to watch it, but many volunteers wish to know about priv changes.
howtosupport is an unofficial community with tutorials about writing Support answers and understanding various aspects of LiveJournal that frequently come up in Support.
Other Helpful Communities:
All of these are helpful in their own way, but most volunteers will not want to watch them all. You should see which you find tend to be most useful for you.
lj_biz is for the discussion of LiveJournal business matters.
changelog is where changes to the LiveJournal code are announced.
lj_dev is where development changes are discussed.
lj_maintenance is where outages and network problems are announced.
lj_userdoc is for discussing the FAQs and guides.
news is where important LiveJournal news is announced.
paidmembers where news related to paid user accounts is announced.
Why Answers Don't Get Approved
Support takes patience and dedication and new volunteers should not expect to get approvals or points quickly. How long it takes will depend on what skills you enter Support with, 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 also screened.
Another common reason for new volunteers not being approved is that their form doesn't meet Support standards. Support likes to have 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.
Answers should always be in one complete screened answer. If you notice you made a mistake, resubmit a new complete answer without the mistake. Do not submit a correction. Since yourr answer hasn't been approved yet, the corrected version can be sent to the user. Almost every volunteer will mess up sometimes and re-submit. There is no reason to worry about resubmissions. However, if you find you are constantly resubmitting answers, then you should proofread more carefully before you answer. You may wish to write your answers in a text editor so that you can see them more clearly.
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. An example of this is a user asking for a source code to start a journal. The user probably means they want an invitation code, so there should be a brief explanation of what each code is and how each is used. Finally, the answer must address any other issues the user needs to be informed of, but wouldn't have known enough to ask about.
One example of this is a user asking an unrelated question, but the account is not validated. Validation must always be addressed when it comes up as not being validated will lead to several problems for the user.
For more information on why your answers weren't approved you can ask in helpscreening. Please read the community's guidelines.
Remember, if no answer has been approved yet, then wait to find out what will be. Sometimes simply no one qualified to handle the request has gotten to it yet. If no answer is approved yet, your answer may be fine.
How to improve at Support
There are several things you can do to get better at Support By reading this, you've already started. Another is to go through the memories for various Support communities. A good way to improve 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. 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.
Read over your answer carefully. Is it well-written? Is it spaced nicely? Does it include references when needed? Did you mention every FAQ you used?
Think about what the user knows and what the user needs to know. Try to make sure your answer provides all the information the user will need to resolve the issue. Also make sure you address any misconceptions the user has or alternate methods of accomplishing the goal.
Learn the FAQs and check them every so often, since they do change. An answer that doesn't include a relevant FAQ will almost never be approved. Part of being able to answer most Support requests is knowing where the relevant information is.
Look over the information provided with the request. Is this a logged in user? Is the account validated? Is the user free or paid? These things may have an effect on the answer.
Try to answer questions and check back to see what got approved. How was it different from your answer? If it was your answer, then great. Look at requests you can't answer, and check back on them to see how they do get answered. Ask questions in HelpScreening and get a review. After you have learned the basics of a category, you may wish to inquire about getting a mentor.
Reviews
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. To get a review, contact the admin(s) of the category you are interested in. They may not review you themselves, but they will make sure someone competent does. If you do not know the admin(s) for a category you are interested in, submit the request to support@livejournal.com and ask them to forward it to the relevant admins.
There are four basic methods used for reviewing. The first is that you collect requests to be reviewed. The second is that you collect requests to be reviewed that are then supplemented by the category admin. The third is that you request a review and the category admin collects all of the information. The fourth is that you are given example requests to answer, which will then be reviewed. In any of these cases, you may also be asked to comment on what you did and why and anything you learned from the request. If you do not know which type of review a category uses, ask.
To gather requests for a review that uses requests from the board, go to the Support board and filter to "You Replied" and whatever category you want a review in. Do not remove any requests from this filter unless you are specifically instructed to.
Then make an email with the URLs to each request in that filter. Include your username and whether you have any privs in that category, and if so, which privs. If you have any specific questions about some of the requests, include those as well, that way the reviewer can address them.
How helpful a review is really varies. Some volunteers find them to be the best way to learn, others do fine on their own. Sometimes a review happens at just the right time to help a volunteer improve further, while other reviews for the same volunteer don't help much. But they are definitely worth a try. New volunteers should generally get a review in any category they've been working in to a moderate extent for two weeks or more. Then get another after about three weeks or so, longer if you spend a significant amount of time away from Support during that time. Volunteers with all of the interim privs should generally be reviewed more often. These are just rules of thumb and will vary from person to person and category to category. Always feel free to ask a category admin about what they think is best for you.
When you get your review, you should expect comments on how your answers could be improved. But do not expect every request you submitted to be mentioned in the review. Often several requests have the same problem or were all done well. In these cases, there is little to say, and they will often simply be removed. If a large number of your requests are removed you either likely do a lot of similar request types or are doing very well.
A review can take a while to get done, especially depending on the size of the review, the time of year (around holidays many volunteers may be away or busy), the category, and just luck. If you don't hear back about a review you sent after a week, send an email asking if it was received and whether everything is okay. Sometimes emails get lost or misplaced, and we don't want any volunteers being ignored through such accidents. If another week passes, send another reminder, the admin may need to get in touch with the volunteer doing the review to make sure no problems came up.
Your review or its summary will then likely be shared with the supporthelp privs for that category. This is to help the supporthelps to better teach you about Support, and because in most categories the supporthelp privs help to decide when new volunteers are ready for different levels of privs.
If for any reason the requested review format causes problems for you, discuss it with the admins for the categories you are interested in. These formats tend to be easiest and work best for most volunteers, but special arrangements can be worked out at times to meet a particular volunteer's needs.
Mentoring
Some categories have mentoring programs. 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 they can go to for advice and answers.
Some categories may have a waiting list for mentors. Some categories may limit mentoring to those who have already earned at least I1. You should check with the category admin(s) for specific and current information. As always, if you don't know who they are, you can have support@livejournal.com forward the request for you.
Support Privs
There are many privileges or "privs" associated with Support. A priv is what gives someone the technical ability to do something. 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 group of people with any of the interim Support privileges are collectively referred to as the interim privs.
All Support privileges are given on a per category basis. Some people will have privileges in all categories, but they either are in administrative positions or have earned privs in each category.
There are four interim privs. They are:
Interim privs will be explained more fully in the sections on I1s and I2s. They stand for interim level one and interim level two. Level one consists of having supportviewscreened and supportmakeinternal. Level two consists of having all of the interim privs.
Supporthelp is the priv that allows a volunteer to approve screened answers and comments. It also allows the volunteer to submit an answer or comment that does not need to be approved, but this is rarely used. It is generally reserved for times when the board is flooded with requests, such as during technical difficulties, to quickly answer numerous requests on the same subject. Another function of the supporthelp priv is the ability to change the summary of a request. The summary is the text that appears on the Support board about the request. Supporthelps generally help to teach newer volunteers how to answer in Support.
Supportclose allows a volunteer to close requests and assign points. This priv is generally reserved for Support administrators.
There are also admin privs that allow someone to give privs to other people.
Understanding the Categories
The following are the public Support categories: clients,
communities, embedding, general/unknown, syndication, user
picture icons, web user interface.
The following are the private Support categories: abuse, account payments, feedback, press, privacy, support@, webmaster.
The public categories are best understood by looking through relevant communities and Support community memories.
The communities for each category are listed below and who should read the community and how it should be used will be explained in the userinfo.
Clients: support_clients
Communities: support_comms
Embedding: support_embed
General/Unknown: support_general
Style Systems: support_system
Syndication: support_syn
User Picture Icons: support_upi
Web User Interface: support_web and web_ui
There is also howto_userdoc which supports the howto journal. howto is affiliated with Support, but not a part of the Support Board itself.
An explanation of the private categories and how they affect Support volunteers is below.
Abuse - this is 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, reporting "hacked" journals, asking questions about suspended accounts, asking legal questions, or asking about the Terms of Service should be moved to the abuse category. Requests from the parents of minors should also generally be moved to Abuse as they need more delicate handling. If you see an abuse request in Support and do not have the ability to move it, check the userinfo for lj_abuse. Contact people who are members of the community and one of them will move it for you, if it is deemed to be abuse-related.
Account Payments - this category 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. Unless the request contains personal information, such as a credit card number, it can generally sit on the board until someone with the ability to move requests sees it. If it does contain personal information, contact a supporthelp priv to move it. You can start by contacting category admins, as they generally are around and have LiveJournal email addresses that are easy to find. You can use the members list for lj_supportadmin as a guide for who can be contacted, but do not email bradfitz about a routine Support issue such as a request needing to be moved.
Feedback - is not currently being used, but might be used at some point to allow people to provide feedback to LiveJournal.
Press - handles requests from the press for information. If someone wants an interview or quotes from LiveJournal staff members, it should be moved to press. These requests can generally sit on the public board until a volunteer capable of moving them sees them.
Privacy - handles questions about the LiveJournal privacy policy or concerns about LiveJournal sending out spam. These are rarely urgent and can sit until moved.
Support@ - handles junk requests such as duplicates and nonsense. For those who can move requests, duplicates should contain an internal comment linking to the other request by the user. These requests can sit until moved by someone with the privs to do so. Support@ also handles forwarding private requests when the category is unclear. If you have the ability to move requests, 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. These requests need to be moved quickly, and if you see one, but do not have the privs to move the request, contact a supporthelp as explained in accounts category. Finally, support@ handles requests about Support itself. If you need to report a complaint or problem with a Support volunteer or the Support system, you can open a request in support@. You can also use support@ to ask private 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.
WebMaster - requests about business issues, security holes, or the death of a LiveJournal user. Security holes need to be moved off the public board immediately, see the accounts category for details.
Special Note: Sometimes we get reports that a LiveJournal user may be committing suicide. While there is only so much that LiveJournal can do in such cases, they need to be handled immediately. Sometimes the authorities can be contacted. Either Webmaster or Abuse can handle such issues. The most important thing to do in such cases, is to make sure it is brought to the attention of the people who can deal with it. Please, do not be shy about emailing volunteers or staff. We would rather more people be contacted than necessary than that the request be overlooked.
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. If the request has already been moved to a private category and sent back, everyone with the ability to move requests will be able to see that.
Also, with requests that should be private, it is even more important that you respect the privacy of the requestees, 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. Ideally, all private requests would go only to private categories, but when they don't, we expect volunteers to act respectfully toward the requestees.
For more information on each category you can see this post.
SuportOffice is down, but I just left the text as if it isn't. And my definition list in part II keeps being broken, but I have no clue why. If anyone can figure it out, that'd be neat.
Anyhow the LiveJournal Support Guide in progress:
So You Want to be a Support Volunteer
Table of Contents
Introduction
Basic Support Rules
How Support Works
Support Rules in More Detail
Support Communities
Why Answers Don't Get Approved
How to Improve at Support
Reviews
Mentoring
Support Privs
Understanding the Categories
Interim Level One
Interim Level Two
Summary Tags
Being a Supporthelp Priv
Leaving Comments
Approving Answers
Reporting Volunteers
Leaving Support
Support Oddities
- Negative Time
- Posted NEVER
- Requests Disappearing
- Multiple Answers or Comments
- Requestees Talking to
Themselves
Social Aspects of Support
- #lj_support and IRC
- Answered With Elegance (AWE)
- Support Bunnies
- Support Cats
- Chinchillas
- The French Toast Support Category
Useful Links
Glossary of Support Terms
Introduction
LiveJournal can always use more volunteers 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. Don't expect to just jump in answering questions and get a bunch of points. For many volunteers it will take weeks to earn their first support point.
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. Some other good resources are the following communities:
lj_support - the main Support community where policies are announced. New volunteers cannot join, but they can and should friend it. Reading lj_support is required for all support
volunteers.
helpscreening - the community for new Support volunteers. Volunteers are encouraged to join and post questions here. The guidelines for HelpScreening are linked to from its userinfo. Both of the above communities have particularly helpful posts
saved as memories. Reading through the memories is a very good way to learn more.
Please note that there is a lot of material you can read, and reading it will almost surely help you do better in Support. But don't feel as if you need to read through everything right now. It's generally best to take things at your own pace. Start with the first three sections of this guide, and then read the rest as you feel ready to learn more.
This guide is designed to answer most of the common questions Support volunteers at all different experience levels have. While reading the sections for more experienced volunteers is fine, there is no reason to feel you should. This is a very long document, and is meant to be read in small pieces as you progress in Support.
Basic Support Rules
There are many Support policies, but only a few that are really important to keep in mind when you're just starting out. For a more detailed listing of support policies, check out the Support communities and later parts of this Guide.
Never contact users off of the Support board. If there is a reason why it is important to do so, then someone who is authorized to do so will. We do not want users to feel harassed or stalked because of their Support requests.
Treat people with respect. This goes for both the people who submit requests and your fellow volunteers. Do not make fun of people who submit Support requests. If you have a question to ask, ask it politely. 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. If you notice mistakes in Support answers, email support@livejournal.com about it and it will be forwarded to the appropriate person or people.
Do not copy other volunteers' answers. You can use other people's answers as a guide to what content yours should include, but write your own answers. If you need help with the wording, ask in HelpScreening.
If a request contains any private information or reports a security bug, do not discuss the request with anyone. As you become more experienced with Support, you will learn how to handle these requests, but until you do, it's simplest to just keep quiet about them. Volunteers who are found discussing private information on the board or using it for their own purposes may be banned from Support.
How Support Works
Users submit Support requests that are then opened on the board as green requests. They remain green until an answer is approved, and then they turn yellow. If they re-open because the user needs more help, they will turn green again until re-answered and say "answered still needs help". When a request closes it will be moved to the closed section and be a pinkish red. Eventually it will disappear entirely, but still be findable by the specific URL to the request. The exact colors may vary from system to system.
As a new Support volunteer your answers will be screened. This means that someone with more experience in Support will read them over and only allow them to be sent to the users if they meet Support's guidelines. There are several Support guidelines both for the board as a whole and category-specific. These will be explained in more depth later.
There are many forms of information in Support requests that you will not be able to see at first. The most notable are other volunteers' screened answers. This means that sometimes you will answer a question that already has an acceptable answer in it. Don't let this discourage you. As a new volunteer you should focus on learning as much as you can. In time you will be able to see these answers.
Sometimes instead of an answer, a comment will be made. 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 followup on a request. Comments can never earn Support points.
If you see a comment in a request asking for more information, you should not attempt to answer the request until the user has replied back. While sometimes an answer will be approved before then, especially if the user seems unwilling to reply back, most of the time attempting to answer such questions will just be a waste of effort.
If you see a request that needs a comment, you can leave a screened answer intended to go through as a comment to the user. Support volunteers can approve screened answers 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 Support, you can leave a message to the other volunteers. Leave a screened answer with the words "INTERNAL COMMENT" all in caps with the information. This will help volunteers to resolve the request. These screened answers can also never earn points, but they do help to get requests resolved. Internal comments should only be used if you have good reason to suspect that the information you can provide is unusual. 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. These further questions must then be answered, but not necessarily by the person who answered the first question. It's a good idea to check back on Support requests you have answered both to see what sort of answer was approvable and to check for followup questions. Once the user is fully helped either the user will close the request or it will sit until one of the Support closers comes to close it.
Requests, regardless of who closes them, can be closed with credit to any answer in the request or without credit. Support closers will attempt to assign credit fairly, but only one person can receive credit for each request. The users may assign points fairly, but they also may close without credit. This is just a natural part of Support. Not all requests are expected to yield points for anyone.
Most requests will take about a week to close. Many will take longer if they require users to comment back, second answers, or new problems. These too will eventually close, but later.
Closed requests can also be re-opened by users. This does not happen often, but when it does the points will be revoked. They may then be re-assigned when the request closes again.
The value of a request is based upon the time the answer/screened answer was submitted. The value of that answer, if the request is closed to it, will be the amount showing at that time, regardless of when it is approved or closed. Most requests are worth one or two points, and the maximum they can be worth is ten points.
Once you have earned points, they will show on your full user info page. You can also see both your points and how it compares to every Support volunteer who has ever earned points at the High Scores page. On that page there will be little numbers in red or green next to many of the scores. This is how much their rank has changed since the last time it was calculated. Points and rank are updated more or less instantaneously. Change in rank is usually updated weekly, but sometimes problems happen and changes in rank will freeze and not be updated for a while.
You can find the specific requests which earned you points in public categories through use of the Support Office. This is not an official LiveJournal tool, but is very useful for Support volunteers. It can do more than just find where you earned points. It is located at http://supportoffice.callete.com/.
Support Rules in More Detail
Support is divided into categories. Each category is run by one or more category admins who can set policies for that category. Thus there are both rules that apply in all public categories and rules that are category-specific. This Guide focuses on overall rules. The best way to learn category-specific rules is through lj_support's memories and the communities for the categories and through the communities for specific categories.
The first rule of Support is that any policy might have an exception if a good enough reason comes up. 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.
The most important rules of Support were presented in the section What rules do I need to follow?. This section goes into detail on more policies. If there is ever a conflict between this guide and information given in official Support communities, then the communities take
precedence. This guide cannot be constantly updated, and the communities can deal with issues as they occur.
There are some exceptions to the rules in the short rules section. Answer copying is allowed with the permission of the person who wrote the original answer, but is highly discouraged for most volunteers anyway. Answer copying makes it harder to learn how to do Support, and thus is generally only used by those who have enough experience already to not need more work on answer writing. Reusing your own answers is perfectly acceptable so long as you modify them to fit the specific request you are answering.
Contacting users off the board is rarely allowed, but if a user writes a thank you post in their journal, you may comment politely to it. If the user friends you, you may then comment to them or friend them if you wish.
Support strives to be courteous, professional, and helpful. While some rules work toward more than one of those, the rules divide up fairly well based on those concepts. This section also explores what those ideas mean.
Courtesy
Courtesy is fairly simple. 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. Learn from answers by other volunteers (when you can tell that they're right), but don't just copy them word for word. If you feel compelled to complain about a common mistake, criticize the mistake, not the individuals who made it. Make corrections privately. Don't ridicule answers.
Specific rules:
- Don't lie to users. There shouldn't be any request that requires you to lie to a user. You can simplify, many users do not need full details, but try to be honest.
- Never ask users to close their requests. If a user is causing serious problems, then email support@livejournal.com about it. Most open requests will get closed naturally.
- Don't tell people to email other users unless it's about joining a closed community or contacting the maintainer to deal with community issues. People do not like 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 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. - Do not misrepresent the names or policies of other sites. For example, "PayPal" should be properly capitilized. Sites that allow remote loading for a fee should not be mentioned as not allowing remote loading at all. We would not want these sites misrepresenting LiveJournal, so we should represent them properly if it comes up.
Professionalism
Professionalism gives people a good impression of both LiveJournal and the Support team. You are expected to act professionally in all Support-related contexts. If you are commenting in an official community and represent yourself as a Support volunteer, then your comment should be professional
and courteous. However, when you are outside Support contexts, your actions may be whatever you wish.
Specific rules:
- Don't use an obscene user picture or username. LiveJournal can have members as young as thirteen, and as such the Support board should remain PG-13. In any case, an answer from someone with an offensive name or picture does not inspire confidence.
- Do not use the words "we" or "us". Support volunteers are rarely allowed to speak officially on behalf of LiveJournal. We do not want to give the impression that we are doing so. 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.
- Do not point requestees to other places when they have support problems. If they have a suggestion link to http://www.livejournal.com/suggestions and tell them to check the prior suggestions. If it is a suggestion that has been shot down many times, you can simply tell them that it has been suggested before and the reasons why it will not be implemented. If it is currently in Zilla or has received positive feedback, then say that the idea has been considered before and may be implemented at some point in the future. Do not point them to the Zilla item.
- Do not give support for things outside of the domain of LiveJournal. We can't Support everything. As such, if something falls outside the domain of LiveJournal, inform the user and try to give them a pointer of where to go to. Such as with complex HTML, suggest they do a web search with their favorite search engine for "HTML tutorial" or similar phrases.
- Do not give out invitation codes through Support. Giving out invitation codes to everyone who asks for one defeats the purpose of the invitation code system and encourages abuse. Likewise, do not link users to communities that give out invitation codes. The invite code
system was created in part to prevent abusive users from getting more accounts from which to hurt people. We do not want to make it easier for these users to hurt others. - If you have a choice of references always pick the most official one. Journals intended for the public such as news are ideal. If there is none, then go with an official LiveJournal community. If there is none, try for a LiveJournal or goathack site with a disclaimer. If not, then
an outside site. Try to avoid linking to Zilla, lj_support, helpscreening, and other sites intended to help volunteers/staff. When including links to LiveJournal posts use the talkread rather than the talkpost form. You want to
encourage users to read comments in the post rather than to comment. - 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 useful for many reasons, if the page should change, 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.
- 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 .... Professional answers give the user an answer-ideally, the correct answer. The exception to this is when the user has been very vague but you think you know what the user is asking about. 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.. Asking for more information or clarification belongs in comments, which can be useful in these situations. However, it is better to answer the question whenever possible than to comment for more information. So, if a simple if FOO then BAR might resolve it, that should be tried.
- Slang and idioms should be avoided in all Support answers. It not only looks unprofessional, but not all users will understand such expressions. Support helps people around the world, including non-native English speakers. Slang and idioms will often confuse such users.
- In general, avoid sentence fragments. All the standard rules of good writing apply to Support answers. Nobody is likely to mind if you split an infinitive here or there or end a sentence with a preposition, but try to write clearly and concisely.
- Avoid phrases like "Hope this helps". It looks unprofessional and some users will read it as a sign of uncertainty.
- Avoid emoticons. It looks unprofessional and may confuse some users.
- 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. It is also unnecessary as the public categories have answers go out with your username and user picture.
- Put your entire answer into one reply. We don't want people flooded with e-mails in reply to their support requests. If your answer has already been sent to the user, and you left something out or made a mistake, then you need to post a follow-up, but try to prevent that from happening. If your incorrect answer is still a Screened Answer, no harm has been done; rewrite it completely and correctly rather than submitting a follow-up. If your answer was incorrect or incomplete, approved, and you do not have supporthelp privs, then submit a correction and email support@livejournal.com with a link to the request and a brief note that you were approved with a mistake that you need to correct. Don't worry that you made a mistake, no one expects you to be perfect, just fix it as best as you can.
- Don't link back to the request itself. The link is added automatically to the response sent by e-mail.
Helpfulness
Helpfulness involves actually giving the user an answer they can use in response to their request. The entire point of Support is to help people. We want to do it kindly and without offense, but we need to make sure that we help them.
Specific rules:
- Always point users toward relevant FAQs. It's good for them to know the FAQs are there and they may find it useful if they run into further problems.
- When including a FAQ from the drop-down, somewhere in the body of the answer there should be a mention of why the FAQ was included. This can be a simple sentence like: The above referenced FAQ explains how to validate your account. The importance of mentioning it is twofold, one 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. 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 unless you are quoting a small excerpt to highlight the information. 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.
- When linking to guides, do not link directly. Use the find?guide= format instead. Ideally, one day all the guides will be translated. The direct links may go to only the English versions while the find?guide= format should go to the version in the user's language of choice. Whether it ends up working this way or not, we prefer to have volunteers get into the habit of doing it this way now.
- 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 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.
- Don't tell users to delete their accounts unless they are asking how to delete their accounts. If you have a really good reason to do so, recommend they back up their journal first, in case anything goes wrong.
- Don't assume the user is using a particular client, web browser, or operating system. If you're not sure, give a generic answer. Explain how to do things with any client listed on the account. If they don't list a client and they want to do something that is easier with a client, mention that.
- Don't mention sites that offer various services, such as remote image hosting, hosting other journals, etc. It's better to tell them to search the web and in the case of images to check with their ISP. These policies change rapidly and without notice. Referring users to a specific site generally causes more harm than good.
- 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. This means that if the user asks about getting a source code, but clearly wants an invite code, you should address the fact that the source code is a different thing from an invite code. Likewise if a user asks about how to add a user picture, but the account isn't validated, you should tell the user how to validate as well as how to add a user picture.
Support Communities
The main journal for Support is lj_support. Every Support volunteer should read it. Official policies are announced there and relevant LiveJournal news is relayed there. Sometimes the direction that LiveJournal Support should take is discussed there. Any volunteer may read it, but only experienced volunteers are granted posting access. Posting access and membership is given when a volunteer earns supporthelp priv in any category of Support.
The next community to consider is helpscreening. This community is open to all volunteers. It is used to give tips on how to better answer in Support and to ask Support-related questions.
All of the public Support categories have communities. They
are:
support_clients, support_comms, support_embed, support_general, support_ssystem, support_syn, support_upi, support_web, and web_ui. Information about them can be found in the userinfo for each community.
Other Support Communities:
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, for the most part there is little worth seeing there for non-members.
support_interim is the community for interim privs. When you earn interim privs, you will be added, until then it is not worth watching.
supportlounge is an unofficial community where many Support volunteers post about their Support experience, amusing Support related events, or share particularly impressive requests.
howto_userdoc is an official community for the discussion of tutorials for inclusion in howto. While not a part of the Support Board, it is closely tied to Support and considered a part of the Support system.
privchange is a journal where the addition and removal of Support privs is announced. No one is required to watch it, but many volunteers wish to know about priv changes.
howtosupport is an unofficial community with tutorials about writing Support answers and understanding various aspects of LiveJournal that frequently come up in Support.
Other Helpful Communities:
All of these are helpful in their own way, but most volunteers will not want to watch them all. You should see which you find tend to be most useful for you.
lj_biz is for the discussion of LiveJournal business matters.
changelog is where changes to the LiveJournal code are announced.
lj_dev is where development changes are discussed.
lj_maintenance is where outages and network problems are announced.
lj_userdoc is for discussing the FAQs and guides.
news is where important LiveJournal news is announced.
paidmembers where news related to paid user accounts is announced.
Why Answers Don't Get Approved
Support takes patience and dedication and new volunteers should not expect to get approvals or points quickly. How long it takes will depend on what skills you enter Support with, 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 also screened.
Another common reason for new volunteers not being approved is that their form doesn't meet Support standards. Support likes to have 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.
Answers should always be in one complete screened answer. If you notice you made a mistake, resubmit a new complete answer without the mistake. Do not submit a correction. Since yourr answer hasn't been approved yet, the corrected version can be sent to the user. Almost every volunteer will mess up sometimes and re-submit. There is no reason to worry about resubmissions. However, if you find you are constantly resubmitting answers, then you should proofread more carefully before you answer. You may wish to write your answers in a text editor so that you can see them more clearly.
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. An example of this is a user asking for a source code to start a journal. The user probably means they want an invitation code, so there should be a brief explanation of what each code is and how each is used. Finally, the answer must address any other issues the user needs to be informed of, but wouldn't have known enough to ask about.
One example of this is a user asking an unrelated question, but the account is not validated. Validation must always be addressed when it comes up as not being validated will lead to several problems for the user.
For more information on why your answers weren't approved you can ask in helpscreening. Please read the community's guidelines.
Remember, if no answer has been approved yet, then wait to find out what will be. Sometimes simply no one qualified to handle the request has gotten to it yet. If no answer is approved yet, your answer may be fine.
How to improve at Support
There are several things you can do to get better at Support By reading this, you've already started. Another is to go through the memories for various Support communities. A good way to improve 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. 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.
Read over your answer carefully. Is it well-written? Is it spaced nicely? Does it include references when needed? Did you mention every FAQ you used?
Think about what the user knows and what the user needs to know. Try to make sure your answer provides all the information the user will need to resolve the issue. Also make sure you address any misconceptions the user has or alternate methods of accomplishing the goal.
Learn the FAQs and check them every so often, since they do change. An answer that doesn't include a relevant FAQ will almost never be approved. Part of being able to answer most Support requests is knowing where the relevant information is.
Look over the information provided with the request. Is this a logged in user? Is the account validated? Is the user free or paid? These things may have an effect on the answer.
Try to answer questions and check back to see what got approved. How was it different from your answer? If it was your answer, then great. Look at requests you can't answer, and check back on them to see how they do get answered. Ask questions in HelpScreening and get a review. After you have learned the basics of a category, you may wish to inquire about getting a mentor.
Reviews
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. To get a review, contact the admin(s) of the category you are interested in. They may not review you themselves, but they will make sure someone competent does. If you do not know the admin(s) for a category you are interested in, submit the request to support@livejournal.com and ask them to forward it to the relevant admins.
There are four basic methods used for reviewing. The first is that you collect requests to be reviewed. The second is that you collect requests to be reviewed that are then supplemented by the category admin. The third is that you request a review and the category admin collects all of the information. The fourth is that you are given example requests to answer, which will then be reviewed. In any of these cases, you may also be asked to comment on what you did and why and anything you learned from the request. If you do not know which type of review a category uses, ask.
To gather requests for a review that uses requests from the board, go to the Support board and filter to "You Replied" and whatever category you want a review in. Do not remove any requests from this filter unless you are specifically instructed to.
Then make an email with the URLs to each request in that filter. Include your username and whether you have any privs in that category, and if so, which privs. If you have any specific questions about some of the requests, include those as well, that way the reviewer can address them.
How helpful a review is really varies. Some volunteers find them to be the best way to learn, others do fine on their own. Sometimes a review happens at just the right time to help a volunteer improve further, while other reviews for the same volunteer don't help much. But they are definitely worth a try. New volunteers should generally get a review in any category they've been working in to a moderate extent for two weeks or more. Then get another after about three weeks or so, longer if you spend a significant amount of time away from Support during that time. Volunteers with all of the interim privs should generally be reviewed more often. These are just rules of thumb and will vary from person to person and category to category. Always feel free to ask a category admin about what they think is best for you.
When you get your review, you should expect comments on how your answers could be improved. But do not expect every request you submitted to be mentioned in the review. Often several requests have the same problem or were all done well. In these cases, there is little to say, and they will often simply be removed. If a large number of your requests are removed you either likely do a lot of similar request types or are doing very well.
A review can take a while to get done, especially depending on the size of the review, the time of year (around holidays many volunteers may be away or busy), the category, and just luck. If you don't hear back about a review you sent after a week, send an email asking if it was received and whether everything is okay. Sometimes emails get lost or misplaced, and we don't want any volunteers being ignored through such accidents. If another week passes, send another reminder, the admin may need to get in touch with the volunteer doing the review to make sure no problems came up.
Your review or its summary will then likely be shared with the supporthelp privs for that category. This is to help the supporthelps to better teach you about Support, and because in most categories the supporthelp privs help to decide when new volunteers are ready for different levels of privs.
If for any reason the requested review format causes problems for you, discuss it with the admins for the categories you are interested in. These formats tend to be easiest and work best for most volunteers, but special arrangements can be worked out at times to meet a particular volunteer's needs.
Mentoring
Some categories have mentoring programs. 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 they can go to for advice and answers.
Some categories may have a waiting list for mentors. Some categories may limit mentoring to those who have already earned at least I1. You should check with the category admin(s) for specific and current information. As always, if you don't know who they are, you can have support@livejournal.com forward the request for you.
Support Privs
There are many privileges or "privs" associated with Support. A priv is what gives someone the technical ability to do something. 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 group of people with any of the interim Support privileges are collectively referred to as the interim privs.
All Support privileges are given on a per category basis. Some people will have privileges in all categories, but they either are in administrative positions or have earned privs in each category.
There are four interim privs. They are:
- supportviewscreened - the ability to see other screened answers 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 or re-green a request
Interim privs will be explained more fully in the sections on I1s and I2s. They stand for interim level one and interim level two. Level one consists of having supportviewscreened and supportmakeinternal. Level two consists of having all of the interim privs.
Supporthelp is the priv that allows a volunteer to approve screened answers and comments. It also allows the volunteer to submit an answer or comment that does not need to be approved, but this is rarely used. It is generally reserved for times when the board is flooded with requests, such as during technical difficulties, to quickly answer numerous requests on the same subject. Another function of the supporthelp priv is the ability to change the summary of a request. The summary is the text that appears on the Support board about the request. Supporthelps generally help to teach newer volunteers how to answer in Support.
Supportclose allows a volunteer to close requests and assign points. This priv is generally reserved for Support administrators.
There are also admin privs that allow someone to give privs to other people.
Understanding the Categories
The following are the public Support categories: clients,
communities, embedding, general/unknown, syndication, user
picture icons, web user interface.
The following are the private Support categories: abuse, account payments, feedback, press, privacy, support@, webmaster.
The public categories are best understood by looking through relevant communities and Support community memories.
The communities for each category are listed below and who should read the community and how it should be used will be explained in the userinfo.
Clients: support_clients
Communities: support_comms
Embedding: support_embed
General/Unknown: support_general
Style Systems: support_system
Syndication: support_syn
User Picture Icons: support_upi
Web User Interface: support_web and web_ui
There is also howto_userdoc which supports the howto journal. howto is affiliated with Support, but not a part of the Support Board itself.
An explanation of the private categories and how they affect Support volunteers is below.
Abuse - this is 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, reporting "hacked" journals, asking questions about suspended accounts, asking legal questions, or asking about the Terms of Service should be moved to the abuse category. Requests from the parents of minors should also generally be moved to Abuse as they need more delicate handling. If you see an abuse request in Support and do not have the ability to move it, check the userinfo for lj_abuse. Contact people who are members of the community and one of them will move it for you, if it is deemed to be abuse-related.
Account Payments - this category 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. Unless the request contains personal information, such as a credit card number, it can generally sit on the board until someone with the ability to move requests sees it. If it does contain personal information, contact a supporthelp priv to move it. You can start by contacting category admins, as they generally are around and have LiveJournal email addresses that are easy to find. You can use the members list for lj_supportadmin as a guide for who can be contacted, but do not email bradfitz about a routine Support issue such as a request needing to be moved.
Feedback - is not currently being used, but might be used at some point to allow people to provide feedback to LiveJournal.
Press - handles requests from the press for information. If someone wants an interview or quotes from LiveJournal staff members, it should be moved to press. These requests can generally sit on the public board until a volunteer capable of moving them sees them.
Privacy - handles questions about the LiveJournal privacy policy or concerns about LiveJournal sending out spam. These are rarely urgent and can sit until moved.
Support@ - handles junk requests such as duplicates and nonsense. For those who can move requests, duplicates should contain an internal comment linking to the other request by the user. These requests can sit until moved by someone with the privs to do so. Support@ also handles forwarding private requests when the category is unclear. If you have the ability to move requests, 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. These requests need to be moved quickly, and if you see one, but do not have the privs to move the request, contact a supporthelp as explained in accounts category. Finally, support@ handles requests about Support itself. If you need to report a complaint or problem with a Support volunteer or the Support system, you can open a request in support@. You can also use support@ to ask private 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.
WebMaster - requests about business issues, security holes, or the death of a LiveJournal user. Security holes need to be moved off the public board immediately, see the accounts category for details.
Special Note: Sometimes we get reports that a LiveJournal user may be committing suicide. While there is only so much that LiveJournal can do in such cases, they need to be handled immediately. Sometimes the authorities can be contacted. Either Webmaster or Abuse can handle such issues. The most important thing to do in such cases, is to make sure it is brought to the attention of the people who can deal with it. Please, do not be shy about emailing volunteers or staff. We would rather more people be contacted than necessary than that the request be overlooked.
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. If the request has already been moved to a private category and sent back, everyone with the ability to move requests will be able to see that.
Also, with requests that should be private, it is even more important that you respect the privacy of the requestees, 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. Ideally, all private requests would go only to private categories, but when they don't, we expect volunteers to act respectfully toward the requestees.
For more information on each category you can see this post.