Agent does not answer ringing call

[James]

How are you all coping with calls that are routed to an agent okay, but the agent does not answer the call? I guess there are several options, such as rerouting the call from the client application, or using PBX features (Call Forward on No Reply, RONA on the Lucent etc.)

I thought a better approach to passing a call to an agent would be to get tserver to make a new call to the target, and then when you get the event answer from the remote tserver, join the calls together. This solution means that the customer is only connected to the agent, and not to a ringing phone. This is also useful if you have capacity problems, failed external route points etc.

Any thoughts? Should I make this a feature request?

[LCD]

Our approach has been to cut off the problem at the source. We developed a daily custom report that shows "Bopped" or Forcedoff calls so that the time and date of the offense are recorded with the agent's name.
Bopped or bumped calls are easily detected when a Ringing Event is followed by the AgentNotReady event. (You can also capture the amount of time between when the call started ringing and when the agent hit Not Ready. If it was a second or less, it was probably an accidental bump).

A similar approach can be used for forced off calls. If the ringing duration exceeds the queue's ring threshold, and is then followed by a Log out event, then it is likely a forceoff.

By providing these reports to the agent's supervisor, the problem is put back in the hands of the people responsible for the problem in the first place. The supervisor can deal with the agent and take whatever steps are necessary to minimize calls not getting answered.

[Victor]

I think this is a simple and probably best solution (have supervisor take disciplinary actions against the agent), but I think there are situations when EventRinging can simply be not answered because of the SoftPhone malfunction.

Unfortunately, it is very hard to admit, but some of the clients who develop their own softphone usually have a rather limited understanding of how to do it, resulting in a rather poor developed application.

I have seen calls dropped, transferred to a nonexistant ACD, put on hold, and never retrieved due to this.

I think a TServer option would be a very helpful thing. One problem is that I am not sure if generating a cosult call for every inbound call is something I would want to do. It would double the link traffic, put unnecessary load on the PBX, and all of this for what? I do not think, to tell you honestly, the resources required justify the cause. At least not in my opinion.

I really would like to see something; however perhaps instead of placing a physical consult call, why not place a phantom one to the SoftPhone only, and when agent answers it, queue the answer request, divert the call from the queue, connect it to a physical phone, and use RequestAnswerCall already generated to answer it? Since all of this can be done in less than a second, agent would not even be aware that the call answered by the softphone was actually a phantom one.

What do you think?
Vic

[James]

We already get a report that gives us this information, but I am trying to create the best experience for the customer. You can discipline your agents but it still happens, so some customers are affected.

The last solution you mention is interesting though... I think I will follow up a bit more on this one...

Thanks

[Mike]

For a Lucent switch you can change the auto answer option on page 2 of the station form to acd. This causes the phone to auto answer all calls queued to the skills assigned to that particular agent logged into the station. Right before a call arrives at an agent station they will hear a short tone to aware them of the call. Hope this helps.