Transfer routing, EXCLUDING some destinations

[JTL]

I've been racking my poor brain on this one, as well as others in the department.

The end users currently use the number of transfers made by an agent to form part of a KPI - they calculate the number of transfers as a % of the total calls taken to see which agents transfer a greater than average number of calls.

Recently, the routing was made more complex, and it is now "normal" for agents to transfer certain calls back to the IVR for specific treatment.

The business want to REMOVE these transfers from the "N_TRANSFERED" statistic, or otherwise generate a different one (for historical reporting) which excludes them.

I did, initially, think of using a piece of attached data, or reusing a current KVP, but this still won't be 100% accurate, as the call could go: Agent A -> IVR -> Agent B -> Agent C, and the presence of the attached data would mean we didn't could the Agent A-> IVR transfer (correctly) but also wouldn't count the Agent B -> Agent C transfer, unless the KVP was updated or blanked - something I'd prefer not to do.

I guess the other "unique" piece of information is the transfer destination. These IVR transfers hit a local RP in a known range (there are either 21 or 24 of these, can't remember) so filtering based on this might be an option.

1) can anyone think of a way to do this which I have missed?
2) would you go for the attached data (and blank it) or try for the RP filter?
3) with the RP filter, is it possible to build a filter which includes multiple values of the RP so we only have 1 filter, and not 21 (or 24) of them?

Hope this makes sense...

[victor]

There are several ways I could suggest moving on this one, with probably quite a few more out there:

1. delete attach data after it is transferred to RP (by updating the key to "")
2. when transfer update value of attached data to that of agent who is doing the transfer
3. filter on OtherDN and calltype=4 and just add NOT to all RPs that are leading to IVR. You can create OR as part of a filter.


I think (3) is the easiest.

Best regards,
Vic

[JTL]

[quote author=victor link=topic=2283.msg8331#msg8331 date=1181212508]
There are several ways I could suggest moving on this one, with probably quite a few more out there:

1. delete attach data after it is transferred to RP (by updating the key to "")
2. when transfer update value of attached data to that of agent who is doing the transfer
3. filter on OtherDN and calltype=4 and just add NOT to all RPs that are leading to IVR. You can create OR as part of a filter.


I think (3) is the easiest.

Best regards,
Vic
[/quote]

Cheers Vic,

So on an "Agent" based report, using your option 3, what's the neatest way to do the report in DMA?

I was thinking 2 stats:

1) N_INBOUND
2) N_TRANSFERED

So I need to filter the N_TRANSFERED based on:

1) OtherDN
2) Calltype=4
3) the excluded range of DNs

yes?

[victor]

Well, on the agent part I would just take N_TRANSFERRED and add filter with "~" (NOT)  for RPs in question. I am not in front of my desk right now, but if you want I can put together a screenshot or two for you.

Wait... Can you use OtherDN as a filtering parameter? I think it was only PairExists. Yeap, I think I am right. So, a quick question - how hard would it be for you to attach data with "OtherDN" and transfer DN via softphone?

Best regards,
Vic

[JTL]

[quote author=victor link=topic=2283.msg8338#msg8338 date=1181228805]
Well, on the agent part I would just take N_TRANSFERRED and add filter with "~" (NOT)  for RPs in question. I am not in front of my desk right now, but if you want I can put together a screenshot or two for you.

Wait... Can you use OtherDN as a filtering parameter? I think it was only PairExists. Yeap, I think I am right. So, a quick question - how hard would it be for you to attach data with "OtherDN" and transfer DN via softphone?

Best regards,
Vic
[/quote]

Actually our Softphone is pretty tied down and developed externally, so that's not really an easy option.

I've got to get a proof of concept sorted by the end of the week, now...

[JTL]

Just looking in the v7.5 statserver manuals, and as well as 'PairExists' type filters, it gives the following as an example:

Suppose you want to set up a filter (DNISFilter2222) that considers calls whose
Dialed Number Identification Service (DNIS) is 2222. To do so, enter
DNISFilter2222 in the Name field and DNIS=”2222” in the Value field. In this
example, the call property is DNIS, the operator is the equal sign (=), and the
constant is 2222

But when I look in the table of allowed 'call properties', OtherDN doesn't appear to be there

[cruel panda bear]

What about what Vic has suggested - adding OtherDN as user-data and then filtering on PairExists?

[JTL]

[quote author=cruel panda bear link=topic=2283.msg8753#msg8753 date=1184148993]
What about what Vic has suggested - adding OtherDN as user-data and then filtering on PairExists?


[/quote]

That's pretty much what I had in mind at the start - however, it isn't always going to be 100% accurate, as subsequent transfers which we DO want to count, would still have the attached data present, and would therefore be ignored in the reports.

There's the option of re-updating the KVP to <blank> I guess, but that's going to get a bit confusing as well...

I will try adding the OtherDN as a KVP and at least getting something off the ground.

Because our Softphone can't be changed, I'm using a potentially 'unusual' way to transfer to out (network) IVR - there's a strategy on the local premise which attaches some transfer data (RP dependent) and then issues a TRoute with basically 'dud' data in it. This causes our network switch (SCP) to 'take back and reroute' the call - so it arrives back on its original (network) DN, except with all of the attached data present this time. The data we attached in the premise-level transfer strategy is then used (in a prestrategy subroutine) to alter the path of the call so that it goes to the IVR instead of rerouting exactly as it did the first time around.

Slightly complex I know...

So as well as adding the Transfer-specific data in the strategy, I will add the OtherDN as a KVP, and will hope it works. Would prefer to be doing this at Softphone level, but don't have the option...

[JTL]

Wooo

Had a quick play around with some attached data. The good news is, if I attached 'ACDQ[]' which is the value of 'ThisQueue' then I get the number I was hoping to see (the RP I have transferred the call to, in order to initiate the TB&T)

Because 'ThisQueue IS an allowable filter (along with DNIS) it should mean I can do this without resorting to attached data, which would need to be wiped out...

So my next 2 questions are stat based:

1) given that I can create a filter based on 'ThisQueue' I probably need to include multiple RPs in the same filter, else I'll end up having to have lots of filters. What's the syntax for adding multiple 'nots' into a filter?

2) am I better, once the filter is made, to try and make a custom stat to report on (within statserver) or am I better using the filter in DMA to filter the existing stat?

[Kevin S]

You can use & (logical "and") and | (logical "or") for doing compound tests.

Just be careful when you start combining & and | with ~, because you may not get the results you expect. If it starts getting very complex (more than two tests), make sure you work it out in a truth table. (You can always look up "Boolean Algebra" or "Boolean Logic" or "propositional logic" on Wikipedia for the basics).

[JTL]

[quote author=Kevin S link=topic=2283.msg8760#msg8760 date=1184168819]
You can use & (logical "and") and | (logical "or") for doing compound tests.

Just be careful when you start combining & and | with ~, because you may not get the results you expect. If it starts getting very complex (more than two tests), make sure you work it out in a truth table. (You can always look up "Boolean Algebra" or "Boolean Logic" or "propositional logic" on Wikipedia for the basics).
[/quote]

Ta

I'm just testing my 'ThisQueue=30001' filter to start with. A single report in DMA with 2 stats. 1 'No-of-transfers-made' and the other the same stat, but filtered. I've logged an agent in and made 6 or 7 calls to it, and transferred some to 30001 and some to 30002, so hopefully I'll have different numbers when I look at the chunk in a couple of mins.

Once I see the difference, I'll build a logical expression. I can get my head around the logic, but wasn't familiar with the syntax - and good old Statserver manual doesn't seem to give a compound example.

[Kevin S]

Two thoughts for you:
1 - You *may* need to restart the Stat Server to get the Filters recognized properly. I have had cases where I have been able to create and use them immediately, but there have been other times where I have needed to stop and restart to get the filters to work correctly.

2 - I will often use CC Pulse as my "sandbox" when I'm trying to test new filters, statistics, and layouts. Once I get the results I want, I can show it to the business and get their approval; I then create the historical report.

[JTL]

Hmmm...

Its not working. I didn't expect it to work in CC Pulse, so I didn't try it there.

I put the filter in the Historical statserver and restarted it.

I actually made 5 calls and transferred them all. I have '5' showing in the 'number of transfers' column, but '0' in the filtered one - so it is disregarding all calls.

I should say, this is an Agent report, but I would still expect it to 'notice' that attached or filtered data was in place for these calls...

Any clues?

[Kevin S]

Just for giggles - try changing the filter to [b]ThisQueue="30001"[/b] (quotes around the data value).
I had tried the same thing with a non UData value (Reason = "1"), and it didn't work until I put the quotes around it .

[JTL]

[quote author=Kevin S link=topic=2283.msg8764#msg8764 date=1184171935]
Just for giggles - try changing the filter to [b]ThisQueue="30001"[/b] (quotes around the data value).
I had tried the same thing with a non UData value (Reason = "1"), and it didn't work until I put the quotes around it .

[/quote]

Cheers Kevin - it *might* already be set like that, but I'll check tomorrow. I followed Genesys' DNIS example from the Statserver manual, so it is bound to be wrong.