Virtual Hold Analyser

On this project we have implemented and rolled out out Virtual Hold.

Virtual Hold Concierge is a virtual queuing technology that educates and empowers callers. When customers are faced with hold time, Concierge tells them their estimated wait time (via Queue Speak Settings), and allows them the choice to receive a callback in the same amount of time as if they had waited on hold.

Virtual Hold Rendezvous provides scheduled callback (Appointment setting) capability. When the contact centre is closed, or when it is not convenient to receive a Virtual Queue call at the quoted time, Rendezvous allows customers to schedule a callback at a time that is convenient for them and the contact centre.

Outbound dialling is initiated by the Virtual Hold Queue Manager component using Genesys T-server to make “TMakePredictiveCall” requests. The pacing of dial request is controlled internally within the Virtual Hold application.

Over the last few weeks we have noticed an increasing number of failed callback dial request due to “technical” errors. The suspicion is that this is caused by a lack of Avaya resources (trunks or call classifier ports).


Fundamentally in VHT 6.7.2 there is no way of controlling the pacing of the dial requests other than to limit the number of callback requests offered and hence scheduled.

Looking for concurrent callback dial attempts is like looking for a needle in a haystack so it was time to write yet another analysis tool to take the historical data from the VHT reporting database and then construct a timeline for each callback.

The output from the VHT Analysis tool is an Excel spreadsheet. The workbook contains a worksheet for each hour in the day. Each row represents a callback request and each column represents a 15 second time slice. Each cell is coded as follows:


The figure below shows an example of 4 normal (successful) callbacks and one failed callback. The fail occurs just 1 minute after the callback was originally requested:


The figure below shows examples of callbacks being retried on both busy and no answer:


Here is the output showing callback concurrency and some fails:



Hopefully I can now get to the root cause of the problem quickly.