An Example Customer Support Problem

Situation

At around 09:30 on Friday the 16 th of January, we received a technical fault call from Anglia Ruskin University. The fault concerned their VMAIL2000 voicemail system and was thus passed to me (I am the senior voicemail support engineer in addition to my role as Training Manger). I was especially familiar with the system configuration used by this customer because I had been responsible for the original installation several years ago.

Site contact Debbie Johnson had been experiencing intermittent faults with the voicemail system – occasionally calls to the system were going unanswered. I had already trained Debbie to Administrator level on this product about a year ago and she was entirely capable of diagnosing most problems on her own. After some experimentation on her part she had tracked the problem to one of the seven incoming ports (lines) used by the system to answer calls. The port in question was not answering any calls. System-wide this meant that one in seven calls were not being answered.

The fault she reported to me was an apparent failure of voicemail port 7. Her mood was very positive throughout, due primarily to the excellent level of customer support that she had always previously experienced in her dealings with our organization. This occasion would be no exception.

Diagnosis

My first step to solving a technical support problem is always to gather as much information as possible. All of our systems are equipped with remote access modems, allowing the engineers to “see” and interact with the equipment from our headquarters. This remote support capability is critical when dealing with customers based in locations vast distances away (some of our customers are based outside the UK). In fact, this particular customer was based only about 8 miles away. Nevertheless, if a problem can be cured remotely then it will always be faster to do so.

After some initial difficulty gaining a remote connection to the system I accessed the system event logs. The logs told me that the port that was suspected to be malfunctioning had indeed been non-responsive for several days. A check of the programming associated with the port enabled me confirm that everything was correctly configured. I asked Debbie to try switching over the dead port with one of the live ones, a simple experiment designed to determine whether the fault lay with our system or with the actual telephone socket (which would be the responsibility of the customer). This caused the problem to switch from one extension number to another and proved that the voicemail system was at fault.

I was now able to conclude that the fault lay either with the voice card (a component within the voicemail computer system) or with the voice lead (the cable that connects the voice card to the customer's telephone system). Since neither of these faults could be remedied remotely it was going to be necessary to visit the customer in person. Given the proximity of the customer I was able to report to Debbie that an engineer would be on-site in less than two hours. I completed the remote support phase of the operation by completing the initial Fault Record Sheet documentation.

Resolution

The engineer with ownership of a fault is not necessarily always the same engineer to be dispatched when that fault requires on-site intervention. In this case however I was both the most experienced with the product and the most experienced with the site, and was obviously the logical choice for the visit.

Visits to customer sites require smart attire and an attitude that is both professional and diplomatic. Typically customers are very welcoming of support engineers – we are, after all, there to help them. Nevertheless it is always necessary to be able to understand the situation from the point of view of the customer. This makes it easier to pacify a potentially frustrated customer and to help make them feel that they are valued. As an organization we always strive for total customer satisfaction and have a track record of going above and beyond the call of duty to achieve this.

In this case Debbie was more than happy with our speedy response time (I was on-site in less than an hour). In the interests of both efficiency and minimizing system downtime I attempted to resolve the problem by replacing the voice lead since this was the less time-consuming of the two procedures. This proved ineffective and I was forced to deactivate the system, open up the casing and replace the internal voice card At all points during the procedure I ensured that Debbie was aware of what I was doing, the effect on her communications system and the expected durations of the procedures.

With the work completed I reactivated the system. Initial testing seemed promising. Whilst more demanding autonomous self-checking was performed by the system I had time both to complete my on-site documentation and to informally discuss the performance of the system with Debbie. This prompted her to reveal a couple of other minor system oddities that she had noticed but that she had not been sufficiently concerned about to bother reporting. I was able to rectify these additional issues very easily whilst on-site, and also modify the configuration of the system modem to make future remote support a little easier. If it is necessary for an engineer to visit a site then it is always a good idea to get as much done as possible whilst there. In this case I was also able to make various system backups and provide general advice about the system to Debbie.

With all the work and testing completed I made sure that Debbie was satisfied that all was now well. The whole visit had required less than an hour, and (most importantly) the customer was happy.

Advantages

The primary advantage of this approach was obviously that it successfully remedied the problem completely, and no other approach could have achieved this. It would have been possible to partially remedy the problem remotely by using configuration changes to prevent calls from being given to the non-functioning port. However, this would have reduced the call-handling capacity of the system and would certainly not have been acceptable to the customer as a full term solution. It would only have been useful as a short term fix in the event that no engineers had been available to visit the site.

Another (equally important) advantage of a site visit is that it allows closer contact with the customer. As effective and highly regarded as our remote support is, it seems that nothing is more persuasive to a customer that they are getting their money's worth from a support contract than the sight of an engineer working on their premises. It also encourages the customer to discuss their level of satisfaction with both the system and the support that they have received if they have not recently spoken with their Account Manager, and allows the engineer to reinforce the message that we are always happy to hear from them. This kind of investment in the relationship between the company and its customers pays off in the form of increased customer tolerance when problems do occur and also in an increased likelihood of continued future business with the customer.

Lastly, during a site visit an engineer is able to carry out close inspection of a system that simply cannot be done remotely. Sometimes this results in the discovery of additional problems that had not yet become apparent to the customer and the engineer is able to remedy them as part of the same visit.

Disadvantages

It is inevitably faster and more efficient to remedy problems remotely where possible. This is particularly true when dealing with a customer that is located so far away that a site visit would require an entire day of an engineer's time. When such a long distance visit is unavoidable then it is often a good idea to pro-actively visit other customers in the same vicinity in order to gain the maximum benefit for the journey. In this case, the customer was located very nearby and so the disadvantage of a site visit was minimal.

Care to e-mail us? Then please click here e-mail