QueueMetrics > QueueMetrics installation

IVR Selection

<< < (2/2)

QueueMetrics:
This is because the standard behavior of QueueMetrics when running with filters and multi-stint mode as well, is the following:
 
- get the full set of calls
- filter out those who do not match the criteria
- aggregate multiple stints out of remaining calls
 
As you only have the IVR information on the FIRST call, if you run a filter in multi-stint mode, only the FIRST stint will pass the filter; this way, the second stint is not found when running in multi-stint mode. This is a natural extension of what is explained in chapter 12.1 of the User Manual, so we do not consider this a bug.
 
This is the way QM has been working so far; you could easily get that working by adding a second IVR record for the second leg of the call.
Like e.g.:
 

--- Code: ---1289928508|1234.1|A0|NONE|INFO|IVR|123
1289928508|1234.1|A0|NONE|ENTERQUEUE||123-5551234
1289928538|1234.1|A0|NONE|EXITWITHTIMEOUT|1

1289928540|1234.1|A1|NONE|INFO|IVR|123
1289928541|1234.1|A1|NONE|ENTERQUEUE||123-5551234
1289928611|1234.1|A1|Agent/3347|CONNECT|70|1235.2
1289928624|1234.1|A1|Agent/101|COMPLETECALLER|70|13|2

--- End code ---


This works just fine.
 
On the other side, I think that if we change the order of execution doing multi stint aggregation before filtering your problem should go away. We expect to do just that for the next version.

Navigation

[0] Message Index

[*] Previous page