# Connexions

You are here: Home » Content » Creating Effective Support Tickets

### Recently Viewed

This feature requires Javascript to be enabled.

# Creating Effective Support Tickets

Module by: Warren Myers. E-mail the author

Summary: Creating and updating support cases in an effective manner is essential to timely problem resolution

## Introduction

I spent quite a while working in an enterprise Tier 2/3 support role, and have had extensive experience interfacing with software systems support engineers both prior to and after that role in support. This guide is intended to provide an introduction to the most effective techniques for creating, managing, and closing a support case from both the supportee and supporter views. As a supportee opening a case, what are the salient things the individual who will respond to your case going to be looking for? And as a supporter trying to solve a problem, what would be the best thing(s) for your customer/reporter to provide to you?

While every application will have different specific needs, there are myriad overlaps between systems, and knowing how to interact effectively with the product's support team is crucial to the successful use of any environment.

## Note:

If your vendor has a specific policy regarding ticket reporting and case creation, by all means follow their guidelines - if they vary from this guide, make sure you do what they ask, when they ask!

## Identifying the problem

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.

## Helpful case titles and descriptions

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: ...
This shows the support engineer what you are seeing, and what you have already done - both of which you will be asked for!

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.

## 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.

## Content actions

### Add module to:

My Favorites (?)

'My Favorites' is a special kind of lens which you can use to bookmark modules and collections. 'My Favorites' can only be seen by you, and collections saved in 'My Favorites' can remember the last module you were on. You need an account to use 'My Favorites'.

| A lens I own (?)

#### Definition of a lens

##### Lenses

A lens is a custom view of the content in the repository. You can think of it as a fancy kind of list that will let you see content through the eyes of organizations and people you trust.

##### What is in a lens?

Lens makers point to materials (modules and collections), creating a guide that includes their own comments and descriptive tags about the content.

##### Who can create a lens?

Any individual member, a community, or a respected organization.

##### What are tags?

Tags are descriptors added by lens makers to help label content, attaching a vocabulary that is meaningful in the context of the lens.

| External bookmarks