0.1 Creating effective support tickets  (Page 2/2)

Communication

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

Resolution

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.