This class of problem may just be the bane of the support professional’s existence. They are the calls we hate to get, but which always, eventually, come to the surface (no pun intended).
I’m speaking of the problems which, apparently, cannot be duplicated… and yet, which will not go away.
I’ve referred to them before as Loch Ness Monster problems. They remind me of the nursery rhyme:
Yesterday upon the stair, I saw a man who wasn’t there.
He wasn’t there again today. I wish that he would go away.
Given that wishing is a notoriously unsuccessful technical strategy, what does one do about these?
As a general rule, a problem is not solvable unless it is duplicatable. This might seem obvious to some, but I don’t think it is commonly known amongst our user base. In other words, if a problem cannot be duplicated, then we can’t isolate a cause; if we can’t isolate a cause, then we can’t break the process down until the actual problem can be removed.
Still there?
When we come across the Loch Ness Monster of technical problems, then, our main goal is to transform it from a problem which cannot be duplicated, into one that can. That is, we keep watching — we are confident that there is a reliable chain of events which is causing the problem, so our hypothesis is that there is something the problem instances have in common which we have not yet noticed. We hope to isolate this missing piece to the puzzle so that our Loch Ness Monster can become verified, analyzed, and eliminated. (Okay, there my analogy breaks down, since I suppose environmentalists everywhere would protest the elimination of a verified Nessie. Fortunately, computer problems are not an endangered species with fanatical advocacy groups.)
Due to the nature of these issues, a big part of the problem-solving process is actually our communication with the user.
- Be a believer. Since the problem can’t ever be duplicated, chances are the user feels a little embarrassed, possibly foolish, and might even be afraid that you don’t actually think there is a problem. (Sure, you saw a monster in the lake… mm-hmm…) This puts the onus on us to assure the user that we are taking their problem seriously, even though we may not have actually seen it in action yet.
- Explain the first steps. Due to the fact that you can’t solve the problem until you isolate it, the other danger is that the user may feel like you aren’t doing anything to help solve the problem. Again, the resposibility is yours to explain to the user what you are doing — that you need, vitally, more information about the issue. Make sure they know that any information at all about when or how the issues are occuring may help bring a solution, and ask that they communicate any new instances as they happen.
- Look for what’s different. The one thing you can do is attempt to determine if there is anything different about the particular configuration of the problem-owner’s hardware or software; if possible, you can compare settings, and so forth, with another user with a similar hardware/software setup (this second user, presumably, is not experiencing the issue; however, even if they are, this just gives you more information to attempt to isolate it).
- Communicate regularly. As long as the problem cannot be pinned down, there exists the danger that the user will feel abandoned, or that nothing is being done to help. It’s vital that you follow up regularly to let the user know that you’re still working on it — even if you’ve found nothing. Just reassure him or her that the problem is still on the radar, and in most cases that will be enough. It only takes a few moments, but this will make a big difference.
Most of the points listed above are not actually technical steps to solving the problem — they are customer service tips. So be it; it’s all necessary — especially considering that we need the cooperation of the user to have any chance of isolating the issue and eventually solving it.
