a) Get them to include a Screen Shot, a picture is worth a thousand words!

b) Be human in your instructions. There are no user errors only programmer and designer errors (not literally I know!) so admit that it's your fault and apologize. Remember they won't read your instructions until they have a problem so be humble!

c) if the problem is a report have them fax the help desk the report with the problem penned in on the report.

d) don't give them the impression that you are asking them to do your work for them. Endless questionnaires will irritate the user and the user will answer incorrectly anyhow. In my experience even intelligent people have problems remembering what they did fifteen seconds ago. Where was I...oh yeah

e) ...give them first a memo field to explain their problem and then give them questions about hardware, software, what they were doing and so on. That way they can relieve there feelings by writing in portugese what went wrong before they have to answer what sort of printer was attached. (But see f) In general ask easy questions first and hard questions later. "What color is the screen?" can be surprisingly useful to a developer <g>. Answering simple questions calms the mind and prepares them to answer harder questions (as any interrogator knows). Being confronted with questions that they cannot answer or don't apply is particularly bad early in the process.

f) user information can reduce the amount that the user has to enter. Consider keeping a profile of what each user has or using network management tool to pick up their computer configuration remotely. Why should they have to say what processor their computer has when you can read it off the network? Don't punish the person with the error. That is unless you WANT to deter them from reporting errors!

f1) If the central information is deduced rather than known explicitly (like the version number of a piece of software perhaps) then consider giveing them a list of what you know about their computer and have them either check mark it or put in their own information. Unless your data sucks, then don't bother they will just think you're incompetent.

g) Log FoxPro errors in a database, automatically email the user that you are aware of their problem when an error occurs.

h) Email them when the problem gets moved from one person help desk to developer etc. to another as well -- I know this wouldn't please everyone cause it would make it harder for us developers to bury problems. Let them know who is working on the problem. Maybe they will give the poor maintenance programmer a beer if he solves the problem. In general personalize the process, people become more angry at things than they allow themselves with other people.

Jamie Beerbower

P/S? not that this in anyway implies that I have had to deal with lots of user errors! <g> But prevention is the better part of malice...

>Hi,
>
>Fixing problems may sometimes be a hard task, even harder if you can't figure out exactly what the problem is.
>
>Talking to fellows working at a client's IT help desk, we agreed that it could be a good idea to have some kind of "instruction" to give their users (of computers and computer systems - I mean users that make hardware help calls and software help calls), in order to help them in reporting problems.
>
>This instruction should be a way to guide users in describing correctly the problem they are experiencing, contextualizing the occurrence of the problem etc. Doing so we hope to have improved eficiency in solving problems, and user satisfaction.
>
>Any sugestions?
>
>Thanks,
>
>Fernando