What do you do when you can solve a user's problem, but you can't <i>explain</i> it?
Many of the problems I'm called for are teeny mysteries. Gremlins, if you will. (I mean these gremlins, not Joe Dante's Gremlins.) These calls are about program settings that have changed mysteriously, or an e-mail that won't send. Gremlins don't cause emergencies, usually just annoyance. But if a user's work is interrupted, they're right to give me a call.
Often, these transient problems are quickly resolved. A trip to the system's Display settings can restore the desktop spanning that the user had with his dual monitor setup, and an e-mail that wouldn't send immediately will go off just fine five minutes later (nine times out of 10, anyway). When a user's problem is easily solved during the troubleshooting process, though, it makes it hard to get at a root cause.
Unless they're obviously a symptom of a larger problem, gremlin calls present a challenge for me. Users want to be assured that their workflow won't be interrupted again, but unless I'm sure I've found the source of the problem, I can't make that promise. To reassure my client that their concerns are being attended to, I usually suggest we keep the system "under observation."
Let me be clear. Just between us techs, these gremlin calls don't stay in my ticket queue on indefinite hold. If I solve the problem, or can't replicate it, I close the ticket. I know my database will store the incident, should I need to refer to it when future problems crop up. My user, though, wants to feel like his concern is being heard, and I can accomplish that easily with a little social engineering. All it takes is a minute or two. I'll ask my user if her problem has come back when we run into each other in the canteen a few days later, or I'll drop a short e-mail message asking how things are going.
I've been doing this long enough to know that not every problem has a cut-and-dried answer. If a gremlin doesn't cause more than a single momentary work stoppage, I'll sleep fine without knowing what happened. What is important to me, though, is having a satisfied user at the end of the support process. When it comes to gremlins, I often find that it's more useful to service the client's perceived needs, rather than servicing their machine.