A question just posed on this forum asked "Popular sites for asking bioinformatics questions?" This is a great and relevant question, but to me is only part of what could and should be discussed. Where is bad to seek help because the help team is too small, too overwhelmed, too unresponsive?
I can think of the NCBI Help Desk with special mention of the OMIM team. They do great work but do not answer the help questions.
I don't mean that this turn into a rant and a post full of flames, but it is good to know where help is less than what it is at other sites.
I think it would help if we could figure out what bad responsiveness is related to, more than naming some bad sites. What do sites/people do wrong? I guess most often they do care (but even that might be a reason), still it does go wrong often. Like all these commercial helpdesks with answering computers, I suppose that these too are intended to be helpful, but it just doesn't always work that way.
Some things that come to mind (but there is probably a lot more):
Be sure you realize that if you run a service people will have questions, even if everything is documented very well. And realize that how well people are answered influences what they think about your service and professional level. People will talk about it! Or mention it on websites, twitter or whatever. So prepare!
You should make sure that there is one clear way to ask for help. If people cannot really find out what to ask where that already starts the problem. If you offer multiple ways to ask the same thing you might forget about monitoring them all. An email to unused email address or a Skype contact or chat box no longer used causes more problems than that it is helpful.
Be sure you really see the questions asked through that single way provided. If you use a generic email address be sure it is forwarded to multiple people (that is why we use an email list that is read buy the whole group).
Be sure to monitor that responses are really given. Often a ticketing system is overkill but you need to know that you answered all questions satisfactorily.
Don't bother people with your own administrative system. If they ask a question they want an answer. It nice to hear that an answer will arrive soon. It is not nice to hear that your question was assigned a ticket number.
Use the questions and answers to set up FAQ lists or even wikis, or at least archive them online. So people can find questions that have been asked before.
Do monitor whether people really were happy with your way answering and the answer itself (but do mot bother them with a 30 min questionnaire if you answer a 10 second question).
Be aware that questions can have very different levels of complexity. Never answer simple questions with RTFM. Copy the relevant part of the manual and provide a link.
If the question appears to be high level, still provide the basics as well, but mark them clearly. So a real expert can easily skip it.
As with any service you provide, do now and then try it yourself! Make that part of release cycle testing or whatever. Links do break, website designs do change which makes it hard to find something that was obvious before so keep track.
Be aware that most people do not ask questions. Every single questions might represent 500 people unhappy with a feature or unclear about the use. So apart from providing the answer also think whether you could improve the service itself so the question will not need to be asked again.