In the tech support field, an Average Call Time is a way to monitor a technicians performance. It is done very simply, by taking a mean average of all calls over a certain time, usually a day , but perhaps a week or a month. Technicians are encouraged to keep their Average Call Time under a certain number, the target.

On the surface of it, this is not a terribly bad idea. When a tech support queue is in the red, technicians should be moving phone calls along as quickly as possible, not getting in heavy discussions with customers about the exact nature of TCP\IP. Overall, keeping calls short and to the point is one of the main purposes of technical support.

The problem with the Average Call Time is that it is an artificial number filtered through at least two different levels of bureacracy. Before you blame a technician for being curt to you on the phone, consider the factors involved.

Most tech support is outsourced. A contract is made between a vendor and a company that specializes in technical support, such as Stream International. The contract will often state that the vendor will only pay for a certain amount of time for each phone call. For anytime over that, the technical support company must swallow the cost. Alternatively, the vendor agrees to pay for the time when the technicians are on the phones, but not for when the technicians are on stand by. They do, this, however, with the understanding that the technical support provider will try to keep these calls down to a minimum time. Anything above that, and the vendor can penalize the provider, or (threaten to?) abort the contract.

What this adds up to is that the on the floor technicians, who are usually separated widely from both the companies they are trying to represent, and even from their own management, must cut corners and do stupid things to meet their average call time target. They also have to be under constant stress, which doesn't make them any friendlier.

For example, imagine this "issue": a caller calls up with their Netscape browser chronically crashing. The agent, being experienced, knows that Netscape is probably hosed. The correct way to deal with this issue is to remove Netscape and reinstall it. It is also 2 PM and there are no calls waiting. But doing this would may take up to half an hour with an end user. So the agent, trying to keep their call times down, tells the customer to scandisk and defrag, and if that doesn't work (which it probably won't) to call back.
So the customer does this and calls back around 6 PM, one of the times when queues are usually stacked. The customer must wait on hold for fifteen minutes, and gets mad at the vendor, and at the poor technician who talks with them. This technician. maybe with a little less experience, or maybe just wanting to get this customer off the phone to keep their average call time and to deal with the queue, tells the customer to go to the Task Manager and shut down all running programs besides Netscape and the two Windows shell programs.
About 20 minutes later, the customer calls back, quite angry by now. This time, however, they have some luck and reach an experienced and responsible technician. This technician does what should have been done all along, a R&R of Netscape. This takes 30 minutes with the customer, but at the end of it, the customers computer works.

The two technicians who passed the customer off in under ten minutes have achieved good average call times. The technician who took responsibility and solved the customers problem got a bad average call time from this.

So, in the end, the average call time creates a headache for the customer, fear for the technician, and causes the company to look rude. Another example of the silliness of the corporate bureaucracy.

To be fair, I was a technician on the line, and so I biased against this concept, as well as not having a full understanding of the reason for its implementation. It does have some good effects, such as discouraging technicians from spending their time talking about that article in the onion today with their customers.

Log in or registerto write something here or to contact authors.