In the world of software development, complaints usually indicate a problem with the way the software is written. But you can’t be too fast to respond to a casual complaint, or a complaint that is too general to provide the needed information required to address the underlying cause of the complaint.
- Track Complaints – Log user complaints electronically. That can be with bug tracking or helpdesk software, but it can also be as simple as using a spreadsheet or tracking comments in a text editor. This will allow you to easily search if a complaint has already been seen before, and how you and your team dealt with the problem.
- Be Specific – Determine what you need to know to solve the problem, and demand that information from the person making the complaint. If you need to know the version of the application, what screen they were using, the steps taken to generate an error message, the specific error message text, etc. to fix a complaint, then demand the user supply these values before you agree to investigate the issue. If it is worth complaining about, it should be worth their time to help you track down the specific issue.
- Duplicate Steps – The user complains that by doing step 1, then step 2, then step 3 you get this exact error message. Great information, so duplicate their steps and see if you get the same error message. Duplication of steps to replicate the issue is important to the developer so they can determine if they have resolved the error.
- Don’t Be Negative – Don’t make things worse by making sweeping declarations (“This program has never worked right!”, or “This always happens”) that will only make people defensive. Acknowledge the reported issue, document the issue as well as you can, and verify the issue by duplicating the steps. You could, although this isn’t always possible, put a positive spin on the issue by thanking the person reporting the issue and telling them how glad you are they are able to help you identify this unknown and complicated issue.
- Errors are Just Errors – Don’t allow yourself or others to confuse an error with a mistake in the way an application is designed. They sound like the same problem, but that isn’t always the case. Just because you get an error when a program attempts to read an .XLS file doesn’t mean the program is broken, it just may have been written to only read .XLSX files. The program works as intended, but the users would like to expand the functionality of the program to prevent the error. This is just an error and the program isn’t broke. Document the problem, determine if there is enough reason to adjust the program, and communicate a workaround to the users.
- Announce Success – Even if you and your developers are recording and fixing user complaints, what happens next? You have to announce when issues are resolved as loudly as the users complained about the original problem. If the users sent you an email to report a list of problems, then responding with a simple email to let them know the issue is resolved is perfect. If the users sent all their problems through the CEO, then you need to make sure the CEO also knows the issues have been resolved. Developers should keep a change log, listing all the user complaints that have been addressed in each released version of their application. It should never be a mystery to the users that their complaint has been addressed.
Don’t just handle user complaints, but help your team solve problems.