Documentation Search: How to open a help desk ticket...

[jbsegal]

... so that you don't make your admins want to kill you...

Has anyone ever seen something like this?

Things I know: "It's broken" is bad. "Fix it" is bad.

More detail is good.

For my local package, screen shots are annoying and should be avoided if possible (the email notification eats the attachment).

Beyond that, there's a lot of luser-friendly advice one can give, and if someone else has already written it, I really don't want to re-write it.

Anyone have any pointers?

Thanks...

Comments

[elaine-brennan.livejournal.com]

How to Report Bugs has, I think, a good start on some of the information you want.

[deguspice.livejournal.com]

If you don't recognize the name of the author, he's the person behind the ssh/telnet client called PuTTY (along with pscp, and the related apps).

http://www.chiark.greenend.org.uk/~sgtatham/putty/

[koshmom.livejournal.com]

While I don't know of any web links to info pages offhand, I do know some guidelines that I can give you:

1. Make the subject line descriptive. Often as the problem is discussed, a subject line of "Help" isn't very descriptive. Put in the application/program having the issue, and a 3-5 word description of the issue with that program. Don't try to be funny or glib, Thus, instead of "M$ Word Sux!!!" you might state "M$ Word won't change a word case in index"

2. Don't try to make too many conclusions as a user. That's the help desk's job. So, instead of saying "It's obviously a database problem" say "I suspect it might be a database problem, but who knows?". If you try to totally diagnose the problem before talkign with the help desk, and the answer is that it's not a DB problem, the help desk is likely to have to waste a lot of time pursuing the DB issue, or try to come up with a politic way of saying "you don't know &*$%!."

3. Come up with an easy-to-follow list of how the help desk can replicate your issue. If they can replicate it easily, they can fix it. And remember, replicating the problem does not mean having to send the help desk all 8,000 pages of your document, if the problem is a formatting issue that can be displayed in 80 characters. It's always best to also start your replication with "Start the program from scratch with defaults. Now change this and..."

4. Let the help desk know at the start if you are under any time constraints to get this issue functional again. It will help them with their prioritization. And also, if it's not despiritely urgent, LetThemKnow! If it's something that you can't continue doing anything until it's fixed, that's much more urgent than "the project is due at the end of the week"....

[rmd.livejournal.com]

also:
0. what are you trying to accomplish?
1. what did you do?
2. what did you think was going to happen?
3. what actually happened?

[majordomo.livejournal.com]

0x3A28213A, 0x6339392C, 0x7363682E?

[jbsegal.livejournal.com]

I hate you.

[intuition-ist.livejournal.com]

heh!

[intuition-ist.livejournal.com]

i write for a living. writing is hard. writing about something that you don't really understand (which has then failed) is *really* hard. so, not surprising that help desk tickets do not achieve a pinnacle of lucidity on a regular basis.

i'm too tired to try to find an answer to this right now. hunt me down sometime and i'll give you a lengthy verbal essay.

[whitebird.livejournal.com]

How about creating an email template or a webform for your customers to use to report problems with?

It doesn't have to be anything spectacular, but something that has easy to follow fields to fill out might do it for you.

[vettecat.livejournal.com]

Slightly off topic, but... answer your e-mail! :-)