A lot of the time we are detectives, finding out what is wrong with user systems. Either the systems they directly use or the systems that support users. Gathering the right information not only speeds up the problem solving process for you, it also helps those you may have to escalate the call/case/ticket to. A lot of the time it really comes down to asking the right questions. As mentioned in a previous post getting error messages, even if you get the user to read it out verbatim over the phone, is a good start.
Often times the end user will not know how to articulate what is wrong. They know things are not operating as they should but are not able to tell you exactly why. Much like a detective taking a witness through what happened the night of a crime. Sometimes you need to lead the user through the problem and a lot of the time they will say one thing that will allow you to start your problem solving.
A good idea is to get the user to walk you through how they normally use the software, it may seem mundane but this technique can help uncover the step that is breaking. It also avoids that "deer in headlights" effect users get when calling tech support. Other good questions to ask are the classic "has anytning changed?", or "has anyone else used your PC?" Getting a time and date of the last time things worked for the user, even if only roughly, helps too.
From here with your knowledge of the problem, the environment the user is operating in, the versions of operating system and software combinations used. You can start your quest to solve the issue for the user. You can remote on and try to fix the problem directly live with the user on the phone. Always a good idea if you feel it is a quick fix. You can also connect remotely (and I am talking Windows desktops here) via RPC and rummage through the event logs. That is why you took the time the application or task successfully last ran, right?
Always give the end user a rough estimate of time for fix, or even better if you can use the ITIL principle of giving the use a work around so you have breathing space to fix the root cause of the problem you should do so.
The other good thing is you are not alone, there are thousands of Windows installs and sure enough you can pretty much bet someone, well most likely more than one person, has encountered the issue you are currently facing. Searching for the event source and event id will often unearth the fix you are looking for. Describing the problem within a search bar can also draw out solutions from forum posts or other internet hang outs. Again this is the reason you went through step by step with the user, to ensure you understand what is going on.
The number one support tool for IT techs when surveyed turns out to be Google search. We are all Google wranglers at some point, but it also helps to be able to problem solve from cold with no back up. Web results can be a good jumping off point but they are no substitute for a good set of problem solving methods and a good understanding of how computers and networks work.
