The use of online, ticket based systems for software support has been growing consistently for years. It is convenient, timely, cost efficient, and provides a first-come, first-served queue environment that is appropriate for properly managed support.
To some customers, however, it seems tedious, unrewarding, and is not detailed enough for their objectives. Using a different approach, customers can improve their capabilities using online ticket support systems and acquire much better results than they believe they experience now.
What is Software Support
Understanding software support may be step 1. Software support is often defined as after sales service provided by a software company in solving software issues, end user problems, and supplying updates and patches. Support services typically include troubleshooting capabilities, installation assistance and basic usability assistance. Training is not typically a service of software support unless specifically contracted.
“My car has a problem”. Ever heard that before? Do you think the mechanic knew what the issue was right away? Most likely not. Providing as much detail as possible on the initial ticket submission is by far the best approach. Provide specific examples. If the issue relates to reports or searches, include the parameters being used. The faster the support personnel can understand the issue, the faster and more accurate will be their reply.
Make the Subject Line Meaningful
When support personnel review tickets, the title is the first thing they see. A subject line such as “Question” or “Why does it do this” do not provide any assistance in understanding the issue before the ticket is even opened. Be concise, such as “Roster report displays fewer clients than enrolled”.
Use Common Language
Understand that support personnel probably do not know your uniqueness or language specific to your organization. They may be replying to dozens of different organizations every day. It is best to use language that is common to the software application rather than organization specific terminology. Otherwise, they are trying to interpret what you mean. If they are wrong, the reply is incorrect. If they don’t know, the process slows down as they inquire about the meaning.
Providing basic usability assistance is typically the extent of the responsibility of support personnel.
Seems obvious, but it is quite common that provided examples are incorrect. For example, support personnel spend fifteen minutes searching for “Bill Smith id# 1250679” only to be unsuccessful because the client was really “William Smythe id# 1250670”. Every inquiry support personnel send back trying to clarify the issue delays a proper reply and slows down the support process. Just as your time is valuable and limited, so is that of support personnel.
Prompts VS Errors
“We keep getting an error message. Can you fix it?” In reality, the user received a message prompt informing them that they could not delete a record because there are related records in other tables. This is not an error. Prompts are valid messages informing the user why a process or function could not be completed. There is little or no need to submit a ticket in these cases as the user already has the information needed to make the next decision.
Don’t Use for Suggestions
Support personnel are typically not the designers, developers, or programmers of the software system. When a user requests a suggested change to the system, support personnel have little or no responsibility to approve or recommend system changes. For that reason, suggestions are best handled outside the support ticket process.
Support Does Not Replace Training
Training is a separate process than support. Providing basic usability assistance is typically the extent of the responsibility of support personnel. Commonly, within online support systems, ticket replies may even include links to already developed knowledgebase articles answering the question posed in the ticket submission. From their point of view, there is often little time nor need to repeat the same language that already exist in the support knowledgebase.
Who Are You
Sounds like an unusual question, doesn’t it? It is more common than one would think that ticket submissions do not indicate the organization or the user making the inquiry. Sometimes the only identification may be the email used. But even then, if using a personal email versus a business email, there may be no way to identify the person and organization.
Don’t Cry Wolf
Emergency tickets are unique in that they are treated in a 911 manner, meaning something is wrong and it must be handled ahead of all other tickets. However, use them sparingly so the intent of the emergency status is not diluted. “I cannot get my deposit report to run” does not classify as an emergency compared to “Users cannot login into the system.”
Don’t CC Too Many People
With many ticket systems, email is an integral feature of the system. Users do not have to log into the ticket system to see replies or to submit replies. However, if more than one user is included in the ticket, every reply from every user will be submitted to the ticket system even when the email was meant to be from user to user rather than from user to support. This can create a very confusing thread of ticket replies to the support personnel, not knowing who the intended target was.
Don’t Wait Until 4:45 PM on Friday
Just about everyone has had to deal with rush hour traffic at some time in their working career. It can be frustrating. Ticket systems seem to have their own mini rush hour on Friday afternoons just before the week is over. Trying to resolve issues just before the end of a week may not be fully possible. Even if the standard goal is to reply to tickets in fifteen minutes or less on average, late Friday tickets may not fare well with that goal and are often pushed to Monday mornings.
The Fix May Not Always Be Shared
In short, every “Why” may not get a “Because”. Many times when a fix is made or an interpretation is provided, support personnel may not have the time nor the expertise to know what happened. Usually they are not the ones making the fix. They are the communicators. They often assist in the research and then pass along the issue or inquiry to the programmers. So when a fix is made, they may not even know why. They know it was fixed and most likely tested it again to be sure before they reply to the ticket.
Photo Copyright: dogbone66 / 123RF Stock Photo