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:
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 though 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 asked by Support volunteers at all different experience levels. 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.
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.
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 is closed it will be moved to the closed section and turn a pinkish red. Eventually it will disappear from the board entirely, but still be findable by the specific URL to the request. The exact colors may vary from browser to browser.
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 individual categories. 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 responses. This means that sometimes you will answer a question that already has an acceptable answer in it. The earlier answer will appear on the request later, when an experienced volunteer approves 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 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 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 response intended to go through as 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. These internal comments 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 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. 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 approved and to check for follow-up 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 approved 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 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 involve asking users for clarification, or answering new problems. Closed requests can also be re-opened by users or by administrators. 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 was submitted. The value of that answer, if the request is closed with credit to it, will be the amount showing at the time the answer was submitted, 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 between the number of journal entries and the number of comments. You can also see your point total and how it compares to that of every volunteer who has earned Support 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 indicates how much their rank has changed since the last time it was calculated. Points and rank are updated more or less instantaneously. Changes in rank are 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. In addition to finding your approved answers, you can also search for screened responses, comments, and internal comments. Support Office is located at http://www.supportoffice.org/.
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 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 's memories and the communities for the 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 Basic Support Rules section. 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, whereas 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 it is highly discouraged. Answer copying makes it harder to learn how to do Support, and thus is generally used by those who already have enough experience 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 goal at a time, the rules divide up fairly well based on those concepts. This section also explores what those ideas mean.
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:
And I noticed that your journal has really poor contrast and you can modify your colors by doing FOO.
PayPalshould be properly capitalized. 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 in return.
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:
weor
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.
HTML tutorialor similar phrases.
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 request is 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 BARmight resolve it, that should be tried.
Hope this helps. It looks unprofessional and some users will read it as a sign of uncertainty.
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 must make sure that we help them.
Specific rules:
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. 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.
The main journal for Support is . 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 . This community is open to all volunteers. It is used for asking Support-related questions, and for supporthelps to give tips to less experienced volunteers.
All of the public Support categories have communities. They are: , , , , , , , , and . Information about them can be found on their respective userinfo pages.
Other Support Communities:
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 to be most useful for you.
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 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.
Answers should always be in one complete screened response. If you notice you made a mistake, resubmit a new complete answer without the mistake. Do not submit a correction. Since your 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 . Please read the community's guidelines. Remember, if no answer has been approved yet, then wait to find out what the approved answer is. Sometimes no one qualified to handle the request has gotten to it yet. If no answer is approved yet, your answer may be fine.
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. 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 and 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 was 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 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 an admin.
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 do so.
Then write 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, so that the reviewer can address them.
How helpful a review is varies. Some volunteers find them to be the best way to learn, while 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. 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 more weeks, 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, depending on the size of the review, the time of year (around holidays many volunteers may be away or busy), and the category. If you haven't received a response to your review 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 usually 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.
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.
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 group of people with any of the interim Support privileges is 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 responses as either answers or 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 describing 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.
The following are the public Support categories: clients, communities, embedding, general/unknown, syndication, user picture icons, and web user interface.
The following are the private Support categories: abuse, account payments, feedback, press, privacy, 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 below and an explanation of who should read the community and how it should be used can be found in the userinfo of each community.
There is also which supports the journal. 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.
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. 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 Abuse 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 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. Ideally, all private requests would go only to private categories, but when they don't, we expect volunteers to act respectfully toward the requesters.
For more information on each category you can see this post.
After a volunteer has been helping in Support for a while they may be given I1, the first interim priv level, in one or more of the Support categories. I1 conveys two privileges, supportviewscreened and supportmakeinternal.
I1 makes Support a bit easier by allowing a volunteer to focus on requests that have not yet been adequately answered. It also includes some responsibilities.
I1s are expected to keep screened responses confidential. They can see them for their own benefit, so they can concentrate their efforts. They should not be discussing these screened responses. If they have questions about them, they can either email the category admin(s) for the category or bring them up in reviews. If an I1 is part of a mentoring program, then they can also ask their mentor.
I1s are expected to understand that not all screened responses are good models. Try not to pick up bad habits from other volunteers. 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.
I1s are expected to use internal comments wisely. While unprivved volunteers have the ability to add internal comments as screened responses, these internal comments will be labeled as such. They are more eye-catching, and volunteers expect them to be important. Interim privs should not be commenting about shortcomings in other screened responses, what should be approved, or what needs to be in an approved answer. But internal comments can be used to share information on unusual requests.
The general guideline for internal comments is only post them 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 Zilla items that relate to the request. Another good use would be linking to a suggestion that is related 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.
Internal comments are expected to be professional. The general guideline is that 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. Many of the internal actions require some text be left, as such, privs are allowed to leave off-topic comments in these cases, but they still must not be offensive.
When you earn your first I1 priv, you will be given access to . This community is a good place to ask questions specific to using interim privs.
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 taking longer.
The primary responsibilities of an I2 are to keep the screened responses and internal comments confidential, to move requests to their proper categories, and to 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 not quite ready to take on training.
Since I2s can change the category of requests and touch requests, they are expected to do so when appropriate. If a request is in the wrong category, the category should be changed first. Always check the category of a request before doing anything else with the request. Please read over the section on the purpose of each private category. It is very important that requests that should be in private categories get moved into them as quickly as possible. Remember, when in doubt, move the request to support@.
To change the category of a request, select "Internal Comment/Action"
and the new category from the drop down, and include some text. This can
be as little as .
if the change is obvious or a brief note about
the request if you have anything to say, and then submit.
Touching a request will re-green it and mark it as still needs
help
. To touch a request, select "Internal Comment/Action" and check
the box to touch a request. Then include some text and submit.
Since I2s can see other internal comments, they can see whether something has been pointed out yet or not. As such, they can use internal comments a bit more broadly. Useful things to leave internal comments about would include the current state of the user's information as it relates to the request. For example, if the user is trying to add memories, you can leave an IC about how many memories the user has. If the user is trying to change the bio, you can leave an IC about what the text of the bio currently is. This makes it easier to tell when the user has succeeded and the request can be closed.
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. If you have made it to I2, you definitely have the ability to become a supporthelp priv if you keep working.
Summary tags can only be added by supporthelp privs, but understanding them may prove useful to any volunteer. Summary tags are designed such that no one needs to remember them or use them, but doing so can save you time and effort. Not all tags are used in all categories. A listing of the tags can be found here.
There are many aspects to being a supporthelp priv. In its simplest form, you answer and approve things on the board. In reality, most supporthelps do much more than that.
Supporthelps have all the obligations of interim privs. They are expected to keep private information confidential and to treat all volunteers and users with respect. They are required to change the category of requests, if necessary, before doing anything else in the request. They 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.
The abilities of a supporthelp are:
Supporthelps are also given membership and the ability to post in .
When you first gain supporthelp, you should look over the Support policy memories in . Some of the entries about policies will be friends-only. You will be expected to know and follow them. You should receive an e-mail that will make this a little easier. The Useful Extra category also has some helpful friends-only material.
Many supporthelps will do more than just work on the board. Supporthelps may be involved in giving reviews, mentoring, answering questions in the Support communities, suggesting good volunteers for privs, bringing up issues for discussion, and reporting volunteers when there are problems. To get involved in these activities, discuss it with the relevant category admins.
Remember, if you do a review you should send it to the volunteer and cc it to the category admin(s). For most categories you will then also be expected to post a summary in the category's community. To find out the specifics of your category, ask the admin(s).
If you do decide to mentor someone, please make sure that you keep in touch with your mentoree/manatee. If you cannot do the reviews yourself, ask someone else to. But it is vital that manatees not be ignored. By accepting one, you are stating that you will handle this volunteer's questions and reviews. If you do not feel capable of doing this, either do not offer to mentor or make special arrangements for the parts you can't handle.
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. We do not expect supporthelp privs to never make mistakes though. 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. We simply don't expect supporthelps to make mistakes such as leaking confidential information or harassing volunteers or requesters.
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 priv can see a request through its entire life-cycle, from possible commenting, to approval, to potential touching, any necessary summary changes, validation nags, and closing comments. By following up on requests, you learn what information is most important to include, both for answers and internal comments.
A validation nag is a follow-up comment that reminds a user of the importance of validating. It is used after the request has been sitting for a few days (how long may vary by category; check with the admin(s) if you intend to leave validation comments) and the account is still not validated. The current version of the validation nag will be sent to you when you earn supporthelp in the general/unknown category. If you need the nag and do not have it, please request a copy. Requests should not be given more than one validation nag.
Comments are used to ask questions or give additional information. Comments should only be used when necessary. If a request is ambiguous, it does not necessarily need a comment. Whenever possible, an answer should simply address all possible interpretations. This is usually faster and simpler.
However, sometimes a request will not contain sufficient information to resolve it. In these cases a supporthelp should comment requesting the additional information.
Comments are also used to correct mistakes. If the approved answer neglects to mention something important, a comment can add that information. Comments are commonly used in validation nags, as explained in the supporthelp section.
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 here or here.
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 information that is important to the request is in a FAQ included in the answer, or in a FAQ linked to from the FAQ included in the answer, then that is generally acceptable. However, if it requires following links beyond that, it is not reasonable to expect the user to find the information and the answer cannot be considered complete.
If an answer is close to approvable, but not quite so, it is encouraged for supporthelps to email the volunteer to improve the answer. It is never required to do so, but doing so helps both the request get answered and the volunteer improve.
If the volunteer is an I2, you can leave an IC stating how you would want to see the answer improved. This is generally easier than emailing, and will usually result in the volunteer seeing the information and correcting the answer.
Supporthelps are expected to approve the first good answer. However, if a user re-submits an answer with small improvements whether to count that new answer as later or based on the time of the original answer is up to the particular supporthelp. As long as you are consistent, it should affect all screened volunteers equally and still be fair.
It is good, but not required to leave explanations of why you approved what you did. In some cases this will be obvious. If it is, you do not need to leave any sort of note. But these notes are helpful both to I2s, so they can learn what the standards are, and to other supporthelps, so they can answer questions about approval easier. They can also save time and effort during reviews.
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.
Particularly good volunteers and Support requests handled particularly well should also be pointed out. However, only those with supporthelp priv in the relevant category should be pointing out such things. These can also be reported to support@livejournal.com. Pointing out particularly good volunteers is often most appropriately done in the community for that category. By the time you have supporthelp, you should know which is appropriate for your category.
Should you wish to stop volunteering, you can do so at any time. If you have privs, you should contact support@livejournal.com to have them removed. If you simply go inactive for a long time, 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.
If you wish to re-join Support after a long absence, you should again contact support@livejournal.com so that you can be caught up as quickly and easily as possible. The Catching Up category of 's memories is specifically designed to assist returning volunteers.
Sometimes weird things happen on the Support board. These can startle or disturb volunteers who haven't seen them before. This section attempts to list some of the unusual things known to happen from time to time.
Probably the oddest is when Support requests get labeled with negative time. Support requests normally show how long ago they were opened. Sometimes the clocks desynchronize and cause the requests to be labeled with impossible times. This will usually get noticed and fixed pretty quickly.
Similarly to negative time, if a request is less than a second old or
believes it is, it will show up on the Support board as posted
NEVER
. In the normal course of Support, you will see these from
time to time. It means you happened to catch the request just as it came
onto the board. It will appear with the correct time at the next
refresh.
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, 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. If a request is moved to a private category, you generally will not be told why, as the reason is confidential. Requests can also be moved to private categories if further issues came up on the request that made it confidential or if the request had abuse implications. Similarly, requests can appear on the board already several hours or even days old if they came from a private category but were able to be handled by the public board.
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 screening system keeps most collisions, as they are called in Support, from happening, but a few still get through. To reduce the chance of collisions and to encourage error-checking supporthelp privs are encouraged to always post screened first and then approve.
Sometimes you'll see comments from the user who opened a request that look like half of a conversation. They may say that the problem isn't something that wasn't brought up yet or add additional information without prompting. These requests can look very odd. What they tend to be are requests opened by someone with support privs. They are replying to screened responses or internal comments that they can see.
This section does not contain any information that a volunteer needs to know. However, whenever a large group of people work together for a while, they will create references that can be rather confusing. This section attempts to outline the tangential creations of Support.
Several Support volunteers hang out on an Internet Relay Chat (IRC) channel. This is not an official channel in any way. It is currently located on irc.lazynet.org on the channel #lj_support. It can also be found through http://irc.callete.com/. You can check its current location or ask questions about using IRC in .
Every so often a list of particularly well-answered requests is posted to . Any supporthelp priv may submit a request to be included in AWE unless they answered the request themselves.
Like many other things in this section, there is really no good reason for Support bunnies. One volunteer, , once answered a request quickly, and the requester came back and said that she was "quick like bunneh". It spread when one volunteer, , created a cute bunny moodtheme. Then several people edited their icons to also include that bunny. The bunny became a sort of mascot of the Support team. Now many volunteers have user pictures that include one or more bunnies. When someone answers requests quickly, they are said to be "bunnies" or "bunnehs", and "bunnying" is when someone always answers a request a few seconds before you.
The cat is a natural mascot for the categories, because the word "category" is often shortened to "cat". While the exact type of cats that represent each category is not currently known, general/unknown is a calico cat.
One volunteer, , became very interested in having a pet chinchilla. Somehow it worked its way into posts and comments enough that many people started making references to chinchillas. The user picture for is at the time of this writing, a chinchilla. Her name is Koala! and the exclamation mark is part of her name.
This is purely a joke. Before category admins had the ability to add and remove privs directly, they would post what changes they want to and would then make them. included in a normal batch of priv changes that she should be given "SuperGodlyPowerOverAllBowBeforeMeMereMortalsAndFeedMeFrenchToast" priv. added supporthelp in FrenchToast to her privs to play along. The priv doesn't do anything and the category does not actually exist, although there have been some discussions about the best way to make french toast and some user pictures of french toast spawned from this.
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, you should always check that the link currently works and contains the expected information. Some of these links aren't official; they are included because volunteers find them helpful.
Support has a lot of terms and abbreviations that volunteers will use without thinking. This can be confusing to new volunteers. In an attempt to make it clearer, here is a glossary of many of the terms used. Some of these are directly related to Support, others simply tend to come up in conversation with Support volunteers or in Support posts or comments. Some of these are terms that are used elsewhere, but since we get questions about them, they are included.
What cat is it in?
Je didn't explain what further help je needed. Jer comments were very confusing.
Screened peoplecan also be used to refer to volunteers with no supporthelps privs.