A key problem associated with supporting complex application software is the time it takes to resolve each incident. For most support organizations, the time to resolve is usually measured in minutes; but when supporting complex applications, it is often measured in hours. One of the most important aspects of resolving the call is taking the symptom being reported and turning it into a well-defined problem.

Is it a bug or usability issue?

According to a recent survey I read, 85% of the calls that come in to a support organization deal with usability issues: the customer is confused about the application; they are not necessarily trying to report a bug.

To help reduce call resolution time, most organizations supporting complex applications have a tendency to put a heavy emphasis on the raw technical skills of their engineers. Although the technical skills of the engineer are very important, the “soft” skills of the engineer can be just as important, at least when it comes to problem definition. After all, if the communication between the support engineer and the customer is ineffective, then it doesn’t matter how technically proficient the support engineer is; a lot of time will be wasted just getting the facts straight.

Who is your customer?

The first step in establishing a good communication channel is toidentify the skill level of the person you are dealing with. In a complex environment, this can be particularly troublesome because the person calling in is likely to be highly educated, even though they may not know anything about software or computers. In other words, it is not unusual for the callers to be unconsciously incompetent.

This lack of computer expertise prevents them from giving your support engineer the kinds of information required to define the problem properly. In addition, the customers are likely to be rather impatient and demanding, simply because they are highly skilled professionals in their own right. This type of customer requires special communication techniques to ensure that the support engineer can move toward a well-defined problem in the shortest amount of time.

Reducing support engineer stress

Clearly, getting a clear definition of the problem leads to lower call resolution times, and, therefore, higher customer satisfaction. However, there is another reason why it is important to improve problem definition: defining the problem is probably the most frustrating aspect of a support engineer’s job. High frustration levels lead to burnout and turnover.

Since complex support environments require highly skilled support engineers, replacing them can take time. Turnover rates that might be acceptable in normal support environments can be fatal to organizations supporting complex applications, especially if the support staff is small.

The solution? Once again, proper soft skills trainingcan help minimize the frustration associated with working through a difficult technical problem. Relaxation techniques and stress management should be a significant part of the training plan, not just an afterthought to technical training.

Solving support complexity from 3rdparties via an SLA

Sometimes, getting a proper definition of the problem requires input from a third-party vendor. In this case, it is not necessarily the application that is complex; it is the operating environment itself that is complex. This can be extremely frustrating, both for the customer and the support engineer. After all, most organizations cannot afford to have a support contract with every vendor that supplies software that “might” interact with their own software.

One way of dealing with this issue is tohave a clear service level agreement. To reduce frustration, it is important for the support engineer to have a clear definition of the kinds of problems that they are supposed to support as well as clear actions to take when the problem falls outside of their area.

Help in this regard can be found from a company called TSANet. TSANet is an organization formed specifically to help resolve multi-vendor support issues. Essentially, member organizations agree to support each other without requiring individual support contracts. This can be an invaluable aid to improving call resolution time.

In short…

When supporting complex application software, it is important to remember that non-technical issues can have a significant impact on the overall success of your support organization. A comprehensive training program that includes the development of soft skills is critical not only for effective problem management, but also for the professional development of the support engineer.

I’d love to hear from you!

Are you managing support for a complex application? Are there situations you’ve faced, or are now facing, similar the ones I’ve mentioned here? Are there other situations you face in your leadership role that have you stymied? Please share your answers to these questions in the comments below, and let’s begin a dialogue.