We are a software company building, selling and supporting our product RecFind 6 as an information management system and enterprise content management system. We have an in-house support department (we don’t outsource anything) and thousands of customers that contact it with questions and reports of problems they are having.
However, like I suspect happens at most software vendors, it is often very difficult for my support people to initially diagnose the real problem. Obviously, if there is an error message then it is easier to resolve but in most cases there is no error message, just an explanation of what a user thinks is the product not working properly.
If we can connect in to the user’s workstation using GoToAssist then we can usually ‘see’ firsthand what the problem is and then help the customer. However, this is not always possible and in a lot of cases my people are working ‘blind’ via phone or email and the only recourse is a question and answer dialog until we get to the point where we can define what the user thinks is going wrong and we can get the history of the problem. That is “When did it start to happen? What changed? Does it happen with everyone or just some users?” Etc., etc.
My people are pretty good at this process but even they get caught occasionally when the customer describes what he/she thinks the solution is rather than what the problem is. This usually takes the form of the customers telling us the ‘fix’ we need to make to the product to solve his/her ‘problem’. The wise support person will always ask, “What were you trying to do?” Once you can determine what the customer was trying to do, you then understand why they are asking for the particular ‘fix’. In most cases, the real problem is that the customer isn’t using the right functionality and once shown how to use the right functionality the need for a ‘fix’ goes away.
Problems also arise when my support people start mistakenly addressing the symptoms instead of the problem. In all fairness, it is often hard to differentiate the two but you can’t fix a problem by addressing the symptoms; you have to go back further and first define and then fix the root problem. Once the root problem is fixed the symptoms magically disappear.
For example, a customer reports multiple documents being created with the same auto number (i.e., duplicate numbers) as a problem. This isn’t really the problem though that is how the customer sees it. It is in fact a symptom and a clue to the identification of the real problem. In the above example, the root problem will be either an auto-number algorithm not working properly or an auto-number configuration with a flawed design. The former is what we call a ‘bug’ and the latter is what we call ‘finger trouble’; the configured auto number configuration was working precisely as designed but not as the customer intended.
Bugs we fix in code but finger trouble we fix by first clearly understanding what the customer wants to achieve and then by helping them to configure the functionality so its works as expected.
All experienced support people get to know the difference between:
What the customer thinks is the solution versus the problem; and
The symptoms versus the problem.
In my experience these are the two most common challenges faced when handling support calls. Recognizing both as early as possible is critical to achieving a speedy resolution and minimizing frustration. Not recognizing both as early as possible leads to longer resolution times and unhappy customers.
If we extend our support experience to real life we realize that these same two challenges face us in everyday life and in all of our social interactions. It why we often argue at cross-purposes; each party seeing the problem differently because of different perceptions of what the real problem is.
The challenges of misunderstanding are also often harder to overcome in real life because unlike a support call which has form and structure, our social interactions are mostly unstructured and opportunistic. We don’t start with a problem, we start with a casual dialog and don’t realize we are about to enter a conflict zone until it sneaks up upon us.
So if you find yourself in an argument please take pause and take the time to ask yourself and the other party, “Just what is it exactly we are arguing about?” Which upon reflection, is exactly how we should handle each and every support call.
If we take the time to properly define the real problem we would spend far less time arguing and making people unhappy and far more time enjoying the company of our customers and friends. It is a no-brainer really, who wants to go through life in constant conflict?
For my part, I will just continue to ask to ask, “Before I address your request for a change would you mind please explaining what you were you actually trying to achieve; can you please show me?” And “What were you doing when you first saw that problem? Please start from the beginning and walk me through the process.” These two questions have worked for me for a very long time and I certainly hope that they work for you.