The first mandate of successfully navigating the support process is to properly identify the issue at hand. A solid knowledge of basic troubleshooting skills is helpful, but - especially the larger the tool - not only is domain expertise needed, individual components of a system may react in unexpected ways. For example, an error may manifest itself in a log file as a component getting an "OutOfMemory" message, when the real issue is that your JVM can't expand its memory usage from the system heap due to insufficient swap space (a specific example that haunted me for over a week on one project).

Be sure to familiarize yourself with the system's log file locations: in all probability not only will they provide initial clues to the issue, but the support engineer will ask for them to be added to the case you create during the process. On a Linux/Unix system, this is typically in /var/log/appname.

The most useful aspect of any support case is a helpful, descriptive title, and a clear explanation of the issues witnessed. The least useful title I can recall having seen was "problem". Not what the problem was, but just "problem". Try instead for something like "Cannot start tomcat6 on Ubuntu 10.10 x64" - this describes the basics of what you are trying to do, and where you are trying to do it!

Adding an initial description to our case title above might look like the following:

After successfully running sudo apt-get install tomcat6 on my Ubuntu 10.10 x64 server, Tomcat will not start.

The following message is showing in /var/log/tomcat/stderr.out: ...

Debugging steps taken: ...

Because you've shown at least some inclination towards being helpful, the support technician(s) are likely going to be more inclined to want to work with you to a resolution. In this specific example, you've identified some errors showing up in a specific log file - go ahead and add that log (or perhaps the whole log directory, if appropriate) to the case so that the engineer(s) you interact with can have a head start on their more advanced troubleshooting steps.

Effective solutions to support problems can sometimes take a long time - and not always because it's a "hard" problem to solve, but individual schedules, time zone differences, support engineer case load, local project demands, etc can all contribute to resolution times not being as optimal as everyone would like.

Remaining professional, even under pressure, is paramount to both sides staying calm, and keeping a specific case at the forefront. As a case opener, try to avoid yelling at the support personell you deal with: you are [likely] NOT the only customer with an issue, and they are a person, too. From the support engineer's perspective, telling your customer they are dumb, stupid, or silly is not going to win you brownie points. Think of it like being at a restaurant: if you are polite to the waitress, she is more likely to be polite back - it a virtuous circle. Alternatively, if you're rude to your waiter, he might be inclined to "forget" things, be sluggish in replying to requests, and all-around just not want to be around you. Professionalism, politeness, and general courtesy goes a very long way towards accelerating a case to resolution.

When support asks for more information, or for the case opener to run/do something and provide feedback, it is important to do so - it allows them to work towards an answer, and will [likely] shorten the overall life of the ticket. Just as important is for the assigned engineer to acknowledge when the customer has submitted something previously-requested - communication is a two-way street, and it shows that both sides want to see the issue resolved.

"Terse verbosity" is the term I like to use for communication in a support issue. Say as much as needs to be said, but no more; be descriptive (verbose), but to the point (terse). Neither side is looking for War and Peace. Both sides are looking for the relevant bits of information that will provide a solution. An example of terse verbosity is shown in the sample description above regarding Tomcat not starting on a server. The sentences could have been written as bullet points. While they are verbose, they are also terse.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." --Antoine de Saint-Exupery

The ultimate goal of any support inquiry is to achieve a resolution. Ideally, that resolution solves the problem found - perhaps via referencing documentation, providing a workaround, or fixing a configuration issue. Sometimes a resolution will be in the form of a bug report. Other times it will be in the form of a "request for enhancement", or RFE. And other times the resolution might be a paraphrase of "sorry, we can't do that".

Achieving a resolution that is ideal for all parties is in the support engineer's best interest, as it will give the customer confidence in your abilities, the commitment of the vendor to their product, and enable the supportee to go about his task at hand in an effective manner. The resolution to our sample case above about Tomcat might be to add storage space (maybe it doesn't have enough temp space to launch itself), or maybe it's to install a newer version of the package, or perhaps it's a configuration issue that can be fixed with minimal changes to initialization parameters.

Regardless of what the resolution may be to a particular problem, it is important for all sides to remember that they are dealing with actual people - in today's digital lifestyle, it can be easy to be rude in an email, or ignore/delay responses to help requests. But being rude, or ignorning/delaying responses will only serve to alienate both parties - perhaps to the point of a resolution never being found, or the vendor-customer relationship to be permanently damaged. As a case opener, you are the face of your company to the support technician(s) who help you. Likewise, as the support case owner, you are the face of the company to the customer. Interactions in these situations are vitally important to maintaining the long-term health of the relationship between these two organizations.