In the 1980's engineering companies had in-house development to enhance and customize software for their needs. As software matured and became more integrated, the in-house support could not be maintained. Key enhancements were still needed to get a strategic advantage in business. One small part of my job for 35 years was reporting bugs and asking for software enhancements. It was thousands of reports in 35 years. I averaged 50%+ of the bugs being fixed and around 30% of my enhancements being implemented. This is about 30 times the average. Some tips are listed below.
Some recommendations to assure you can successfully report problems. This is derived from my experiences with multiple software vendors.
Complaining in a user forum, telling the salesman or even a VP about a
problem will not get it solved. Turn the request in on the customer
support system. Even small software companies have a method for
reporting problems. Find out what it is and use it. Then
keep a record or track of all the problems you report. Check on it
quarterly if it is a long term fix. If you forget about the
problem so will they.
The goal is to fix a problem, not to satisfy your ego. Complaining, name calling and insults are great ways to have your problem dismissed. When writing, talking on the phone or in person remember you want people to be your helpers. Treat people with respect and show gratitude. Many will work hard for you once they know you are someone worth dealing with. Apologize quickly when you do something stupid.
Learn to apologize. No matter how hard you try about 15% of the bugs you turn in will be misunderstandings or user errors. Apologize and move on.
When reporting a problem, don't write the technical details in the first part. The first part needs to be written for a decision maker. The decision maker often knows more about golf than software. Give them information so they choose to fix your problem. Explain time lost, economic and competitive impact. Point out how it will help them to sell more! End with an expectation that the problem will be addressed soon. Praise them into agreement. You want your problem on the top of the stack, not lost in the myriad of poorly presented problems. It needs to be complete, accurate and concise. Long reports will not be understood.
The second part needs to explain the technical details. All of the details. Versions of software, hardware, firmware and OS. Steps to reproduce the problem are critical. Provide examples and pictures whenever possible. If support groups can not re-produce the problem, it will not be fixed.
Software is international. Avoid cultural phrases in your communications. The reports may be read by support people in other countries. Language translators may be used. Meanings of phrases like "in a pigs eye", "house a fire", "night and day" or "the moon and a snapping turtle" confuse more than help.
Proof read what you wrote before submitting. Read it aloud to make sure it makes sense. Use a spell checker. If you were angry when you wrote it, wait a day, re-read it and fix as needed. Focus on the problem, not the emotion.
What priority should your reports be? Always high. Demoting to anything other than high means it will not be fixed. Don't play the rating game.
One motivating trick: When you can show a logic error in the software, it motivates developers to fix the problem. Many developers want to be logical, like Spock. Something like, "A plus B is not equaling C as it should..." may work wonders. Pleasant embarrassment is a powerful tool.
Reports will take time. 2-4 hours per report. If you don't want to invest the time, the problem isn't important enough to you.
Even I forget to do all the steps from time to time, but keep working at it. Success is worth it.
99.9%+ of customer requests are short term or tactical. Bugs and minor enhancements. Customer support groups are designed to handle all these tactical requests.
Customer support groups do not handle strategic requests well. You must submit strategic requests to the customer support group, so they can be tracked. Then you must work through sales and head developers to teach them the need and potential of the enhancement.Companies are like a battleship with a charted course. A strategic change is often a course change and it is not easy to get the captain to change course. You must overcome the blindness the charted course induces and the lack of understanding of management.
Companies that support cooperative development and round table discussions do much better with strategic recommendations than companies that leave customers out of planning.
Strategic requests need careful consideration and support from your upper management. Strategic requests need data, examples, pictures, charts, studies or anything else you can come up with to convince the developers of the needs. This will take more than one paragraph. Be careful, too much text and it wont be read. Get your writing and presentation skills in order. Getting a strategic change takes time, patience and a firm resolve.
My friend was a designer in the early days of computer gaming. They
would get thousands of requests a week. More arrows, change the maze
or add a new level, all tactical. None of the requests told them
what the next big thing in gaming should be.
The strategic change came from an argument. The developers
argued about who was best at playing the new game. One took it so
seriously he worked all night to add a network interface. This
allowed 2 or more players to play each other in the game. They
had so much fun playing it they put it in the official release a few weeks
later. It was a strategic change that lead to the online gaming community
we see today. It seems like a simple thing today, but it was a
revolution in the early 1990's. It was something that had not been
requested at the time.
Sometimes the only way to fix a problem is to switch software vendors. What I believe are the signs that a software company may not be a good strategic choice.
last updated Oct 22, 2024