Many (if not most) companies that deal with customers online have implemented some sort of automated ticket system these days. Generally one is asked to fill out some sort of online form, some specific solutions are suggested (either generically or based on keywords in your query), the ticket is submitted, and finally the user is given some sort of a tracking number or link. I (unlike many of my associates) donÂ’t really have a problem with this system, though this may be based in my years of experience in customer support. I see the solutions (or value adds) provided by this type of solution:

1. Customers are reminded that the solution to many problems (maybe even theirs!) are available immediately, on that very same website


2. The support system has the opportunity to query the user on a few key points, often overlooked when sending an email to a support@ address (OS, Version, ram, cpu speed, etc). Regardless of the messages provided on the page indicating who to mail for support, this information will likely not be included in an initial query.


3. Customers are given a method to update their support request after the fact. Often users resolve the problem on their own in the window between requesting support and the initial response. That resolution may negate the need for a response, or require a response to a new (previously unknown) problem. This updating after the fact is nearly impossible to accomplish in a timely manner with standard FIFO handling of support email


4. Customers can easily enquire as to the status of their ticket without generating additional workload for the support team. The automated system can provide information either queue status, or general support volume (‘Support volume is light, we should be able to respond to the majority of tickets within 12hrs’ or ‘We are currently receiving a large volume of support requests it may take up to 72hrs to respond to your ticket’). With traditional FIFO email handling any request for an update would likely be read after the initial query was responded to.


5. The state based nature of a ticket helps avoid confusion on the part of the support team, as to who is responding to any particular item, or whether a response has already been sent. Occasionally when dealing with support via email I would forward a support message to a co-worker (seeking to expand my knowledge enough to answer the given question), at which point I would file the message, expecting to receive a timely response, which would ‘re-open’ the situation for me. If the co-worker neglected to respond, or explained the situation in a more casual manner (e.g. over lunch) the original request could fall through the cracks.

All that being said, speaking with associates, friends and family, there are several shortcomings to many ticket based support systems that have irritated the world at large.

• Pigeon holed problem options. Most, if not all ticket systems I have seen require you to select your problem type from a series of drop downs. This causes great confusion and consternation for people whose problems donÂ’t fit into one of those neat little categories, or when their problems spans multiple possible choices.


• Confusing problem options. Invariably, when asked to select my problem type, I am given a series of options, generally either only one or a few words each. Several of these options will use technical terms. These short descriptions, combined with language the user is likely either unfamiliar or barely familiar with combine to present a slew of very similar options, none of which sounds quite right.
  
• Long, multi-page forms. Several systems involve answering many questions on a series of pages. Not only does this multi-page system require re-loading a new page every few seconds, but, they also generally suffer from the pigeon holing problem mentioned above. These can compound to lead the user through a tree of pages, abandoning them on a branch far from anything even remotely sounding like their problem.


• Purposefully obfuscated contact options. Many (if not most) support sites make you jump through a series of hoops before they even let you start filling out the support form. Thus ensuring that you not only navigate the support section of the site, but also read the FAQs and run a search. Many users (myself included) will search the site before seeking a contact link, only to find our diligence will be punished by being forced to repeat the same steps within the support system.

I of course, have a few suggestions on how to deal with these problems.

• Pigeon Holed Problems. Always supply an ‘OtherÂ’ option. Users need a quick escape when the available options donÂ’t describe their problem, or they donÂ’t understand the options provided.


• Confusing problem options. Dealing with these really requires a two pronged attack. First, sit the techie down with a non-techie, have the techie describe the problem in a few short sentences (avoiding using the words he/she would like to use in the description) then have the non-techie choose the option. Next, offer possible symptoms with each option. For example under ‘Problems Connecting to the internetÂ’ you could list ‘Cant send emailÂ’ or ‘Cant view web pagesÂ’. This ends up being a large amount of information, you can either get creative with your javascript, or switch to radio buttons for this part.


• Long, multi-page forms. Condense your forms into a single page, and replace question trees with either javascript usage, or intelligent form design. The more questions you ask, the more likely it is that the user will get them wrong anyways, creating even more work when the wrong person gets the ticket. Also consider how often the information is actually used, I canÂ’t remember the last time I answered a question in which the amount of RAM the user had was actually relevant. If it isnÂ’t needed more than 80% of the time, donÂ’t ask.


• Obfuscated support links. The solution to this problem is simple, stop hiding the contact page. Forcing users to jump through searches and FAQs to find the real link at the bottom of some page isnÂ’t going to help. Users who searched for the answer before looking for the contact link will just get ticked off, and those who didnÂ’t donÂ’t arenÂ’t going to read those pages anyways. When implementing this sort of system corporations likely realized that their support volume decreased, this is in fact a bad thing. You are annoying customers, who gave up looking for the answer. This has several immediate consequences: They will not purchase updates in the future, they will not recommend your product to friends, and they will likely speak poorly of your product if given the chance. These are lost sales dollars

What are your thoughts?