Can you tell me what the problem is?
While browsing the web the other day I came across an interesting discussion on how to get users to supply better bug reports with a number of comments from developers, but then a comment was made:
The user can’t tell you details about which internal parts of your code have a bug, they tell you (at best) what they were doing when something happened.
When I saw that it lit up a problem that we see almost every day. While customers can’t tell us what our software is doing internally a lot of our customers don’t even have a basic description of the problem that they are seeing. In some cases we have had to ask half of the customers contacting us outright – What is your problem?
Being able to tell us what you where expecting to get, and what you actually got when working with the software is a great first step in getting any issue solved. If you can’t explain the issue to us we sure as heck cannot read your mind over the phone or email. The best part about describing a problem in terms of Expectations vs. Results is that you don’t actually have to know anything about the product to be able to get meaningful information in our hands.
Getting meaningful information into the hands of the support team is going to help us get a handle on your issue faster and get the issue resolved quicker. That’s a good thing, because let’s face it – nobody really wants to talk to the support team, no matter how nice a group of people we actually are.
