Submitting effective case descriptions saves you money and allows us to respond faster.

One of the grand hurdles with troubleshooting technical issues on the web is communicating the details effectively. This article explores a few tips for bridging the gap between unique perspectives of understanding the problem and then articulating it effectively so a technician or programmer can resolve the issue quickly.

It is critical to master a good process for communicating your technical support cases (tickets). The faster your tech can get to the source of your issue the lower your support costs will be and the faster a solution can be found.

The first and most common mistake folks make is assuming aspects of what needs to be communicated and omitting it. For example it is easy to forget URL’s or steps required for replicating the issue. The first thing a tech support person needs to know is where to look for the problem and then they need to understand the problem completely before they can attempt to solve it.

Useful checklist to consider in a case definition:

• Did you include URL’s for the specific area of the site with issues?
•  What are the steps required for the tech to replicate the issue?
• What is the intended behavior or result of what should be happening?
• What is the problem behavior or missing data?
• Are there vulnerabilities or risks involved?
• Have provided all information required for accessing content; ftp, hosting CP or Joomla Admin?
• Can you provide accurate background information with cause and effect?
• Do you have ideas or suggestions to what may be causing the problem?
• Can you provide screen shots or image mock ups with clear visual representations?
• Do you have the ability to create screen share videos walking through the steps?
• Are there additional questions you need answered?

Remember that one of the first things a tech has to determine once they understand the issue is if this is a configuration issue or is it a programming issue. Meaning; does the software requires different parameter settings to achieve the desired result or is there a code conflict or feature that needs to be added? The clues or breadcrumbs you leave your technician are the key for them getting to the root of the problem faster.

Most of this is all common sense but too often the closer we are to the issue the more we can forget or is assumed and omitted in our case definitions and issue explanations. Failure to get this right will not only make the issue take longer to resolve but require more communication steps (back and forth) to get to the finish line and resolve your issues.