> Since users indeed never learn, stop expecting them to !
I don't expect them to. That doesn't mean I can't be irritated that they don't!
We have various logs and audits too, that can usually be used to work out what has happened. Sometimes alerts based on those logs mean we are already fixing the issue before any user reports it. Even with full audits and other logs, it is usually still quicker to locate and diagnose a problem if given what useful information we know the user has access to (the standard set: approximate time (at least the date if not today), what were you asking it to do, what did it do instead, any error messages they were displayed).
If the user is give a message with a code that explicitly says "report this number when you report the issue" and they don't bother (they just say "I got an error") and that information would save me time, you bet your arse I'm pushing the issue back onto the queue and getting on with some interesting dev/infrastructure work until a better report arrives, or looking at another issue where there is decent information.
Want to be at the head of my TODO list? Then make at least a minute amount of effort to help me help you.
It particularly bothers me when clients who negotiate a discount because they won't need first-line support as they are "big enough to have a department that triages that sort of thing", still send through terrible reports because their idea of triage is just hitting the forward button whenever an email comes in. I've got better things to be getting on with than providing free outsourced work for a bad IT department!
I'm not very customer facing these days, since we have grown to the point where I have a bit of a shield provided by our support/PS/BA teams, which is good for both my irritation levels and the clients!
I don't expect them to. That doesn't mean I can't be irritated that they don't!
We have various logs and audits too, that can usually be used to work out what has happened. Sometimes alerts based on those logs mean we are already fixing the issue before any user reports it. Even with full audits and other logs, it is usually still quicker to locate and diagnose a problem if given what useful information we know the user has access to (the standard set: approximate time (at least the date if not today), what were you asking it to do, what did it do instead, any error messages they were displayed).
If the user is give a message with a code that explicitly says "report this number when you report the issue" and they don't bother (they just say "I got an error") and that information would save me time, you bet your arse I'm pushing the issue back onto the queue and getting on with some interesting dev/infrastructure work until a better report arrives, or looking at another issue where there is decent information.
Want to be at the head of my TODO list? Then make at least a minute amount of effort to help me help you.
It particularly bothers me when clients who negotiate a discount because they won't need first-line support as they are "big enough to have a department that triages that sort of thing", still send through terrible reports because their idea of triage is just hitting the forward button whenever an email comes in. I've got better things to be getting on with than providing free outsourced work for a bad IT department!
I'm not very customer facing these days, since we have grown to the point where I have a bit of a shield provided by our support/PS/BA teams, which is good for both my irritation levels and the clients!