Transfer call reporting - Consult calls etc

[JTL]

Ok, my brain is hurting a little with this one.

Previously in our environment, we had a Network Routing Structure (v7.0 Genspec NTS) and several Premise sites (v7.2 Avaya CM TS).

In order to transfer a call from Agent A to Agent B, Agent A would dial a local RP, which was not monitored by Genesys. On this RP was a vector which would essentially dial a number in the network, and present the call to the NTS. The NTS would then interoperate with the URS in order to select a target (Agent B) and transfer the call to that Agent.

This worked quite well, but obviously we lost attached data (!) and every transferred call, whether it came back to the originating site or not, had to go via the network. Furthermore, Agent B would always be reported as having taken a Call Inbound rather than a Transfer_Taken (if my memory serves)

Recently, I reworked the routing, connecting the PTS up to the URS. Now, instead of the local RP being unmonitored, and the Avaya doing the forwarding to the Network, the local RP is monitored, and a transfer strategy is loaded on it. This strategy targets Agent B, at which point the 2 PTS do their ISCC, and the call is routed accordingly.

Following this, obviously the numbers generated in the reports changed quite dramatically. Inbound calls to a particular pilot team reduced quite a lot, but their number of Consult calls increased - as did their N_Transfers_Taken - but our reporting dept was having a problem working out what was what.

This was made even more of a grey area, when we discovered that a call which went to a different Premise was reported differently to one which stayed on the originating premise T Server, and this is something I need to get ironed out.

So - how can I get single site and multi site transfers to report the same? These are predominantly 'warm' transfers, but I would envisage that blind transfers would behave in a similar fashion - at least for the receiving agent.

[JTL]

Right... my reporting teams are telling me that:

1) if a call is transfered to another site, the receiving agent doesn't have a 'consult call' counted
2) if a call is transfered to the same site, the receiving agent DOES have a 'consult call' counted

Is this expected behaviour?

[guest01]

We had a similar problem when we were using virtual agent groups. Consult calls counted differently for calls coming from other virtual agent groups compared to calls originating and terminating in the same group.

I am scared to ask, but:
- do you have the same statserver watching both t-servers?
- can you confirm that conn-id is the same for the consult call once it arrives to agent on PTS2?
- please confirm that you do not have some fancy filter on your report that only counts local calls

must be something wrong with settings because I'm having difficulties imagine genesys having this problem 15 years since their first t-server.

[JTL]

[quote author=guest01 link=topic=2417.msg9064#msg9064 date=1187181636]
We had a similar problem when we were using virtual agent groups. Consult calls counted differently for calls coming from other virtual agent groups compared to calls originating and terminating in the same group.

I am scared to ask, but:
- do you have the same statserver watching both t-servers?
- can you confirm that conn-id is the same for the consult call once it arrives to agent on PTS2?
- please confirm that you do not have some fancy filter on your report that only counts local calls

must be something wrong with settings because I'm having difficulties imagine genesys having this problem 15 years since their first t-server.


[/quote]

Same statserver watching both T Servers
Haven't checked the ConnID
No fancy filters

Agree, if they provide canned reports, Genesys must have some way of making sure this works consistently.

Should be able to ignore the fact that I have network T Servers and network switches for this piece of work, since this really is just standard intersite routing.

So long as I can correctly count the number of calls each agent receives, CONSISTENTLY, and explain to the reporting departments what they should expect, I'll be happy...

[Kevin S]

Here's a thought...
If you can't capture these calls in a single statistic, what about capturing it in two and combining them into one in a database view? Possibly attaching data and applying filters, so you get data specific to this (these) routepoint(s)?

I'm trying to think to my multi-site days, and I don't seem to remember a call going from Site A to Site B (and TServer A to TServer B) *ever* being counted as a consult call.

[René]

Hi,

It isn't Genesys fault because the call type is determined from the information provided by the switch. If there is no "intelligent" network between your Avaya switches then the destination one treats the transfer call as standard Inbound call. You have several ways to "solve" this situation:
- Ask Avaya to setup some kind of network between the switches so the calls between these will be treated as Internal
- Ask your switch guys to change configuration of Avaya - calls from trunk to switch A has to be classified as internal
- Create new statistic (MainMask: CallConsult, CallInbound) and use that statistic together with filter based on UserData

I had the same trouble several years ago and was able to solve it using custom statistic and filter based on UserData. I would prefer to change configuration of Avaya but I wasn't possible due some side-effects.

René

[JTL]

[quote author=René link=topic=2417.msg9068#msg9068 date=1187202465]
Hi,

It isn't Genesys fault because the call type is determined from the information provided by the switch. If there is no "intelligent" network between your Avaya switches then the destination one treats the transfer call as standard Inbound call. You have several ways to "solve" this situation:
- Ask Avaya to setup some kind of network between the switches so the calls between these will be treated as Internal
- Ask your switch guys to change configuration of Avaya - calls from trunk to switch A has to be classified as internal
- Create new statistic (MainMask: CallConsult, CallInbound) and use that statistic together with filter based on UserData

I had the same trouble several years ago and was able to solve it using custom statistic and filter based on UserData. I would prefer to change configuration of Avaya but I wasn't possible due some side-effects.

René

[/quote]

I hear what you're saying, but beg to differ. As both T Servers are talking to each other (ISCC) to 'arrange' the transfer, it should be possible for the call type to be interpreted correctly. Afterall, the rest of the attached data is available...

[René]

Unfortunately it isn't. In fact the call type "consult" is an internal call between two agents. TServer is able to change the call type because it knows both parties of the transfer. That isn't true in case of multi-site transfer because TServer doesn't know the type of target on external site.

Maybe it's good suggestion to Genesys enhancing ISCC in next release to support this functionality.

René

[JTL]

Rene,

Thanks again for your explanations and help. I carried out some more testing, and investigated the raw data in the ODS to find exactly what was being calculated.

I repeated the same call scenario for a single site and multi site transfer. The ONLY difference is that Agent B in the multi-site scenario, is shown as taking 2 Inbound calls, rather than 1 Inbound and 1 Consult, as happens on the same site. Agent A (who makes the transfer) is correctly shown as receiving 1 inbound and having 1 Consult call in both scenarios.

My problem now, is that the business always used to have a measure of the total calls taken by an agent. Rightly or wrongly, all transfers received were non-Consult, therefore N_INBOUND incremented for each transfer taken. Now, SOME calls will increment N_INBOUND, and some will increment N_CONSULT. However, N_CONSULT also counts Consult calls which are MADE, so they can't be added together. Furthermore, N_TRANSFERS_TAKEN increments in BOTH scenarios, so that can't be added to N_INBOUND either.

I notice that there are statistical types for CallConsultCompleted, CallConsultOriginated, CallConsultReceived and CallConsultStarted - presumably one or more of these can be used to count ONLY Consult calls which are received (I wonder which one?! ) therefore can be added to my N_INBOUND to record the same results as the business are used to.

Does this make sense, and does anyone have comment?

I shall certainly be adding an FR for Genesys to implement something regarding multi-site Consult calls!

[exchelente]

I gave up trying to get stat server (cca/ccpulse) to give me any usable transfer/conference info because of the multi site problem you see where a cross switch consult just shows up as normal callinbound.

[cavagnaro]

What about using KVPs?
An Inbound call without any of the KVP you have on your strategy may be a "consult" call (~(PairExists("myKVP","*")) or you can modify your softphone and add a KVP when doing a consult call (PairExists("KVPConsultMultisite","*"))

[victor]

There is a quirk with VAGs that I was never able to resolve in CCA that would treat call counts for VAG and for people inside VAG differently, so at the end of the day,
I had a problem quite similar to your, and the problem was caused by two things:

1. calls originating and ending in the same virtual agent group counted differently that those were originating or terminating outside the group.

2. multi-site calls would count funny when you have a two-step transfer and both of agents were part of the same VAG.

So, what we did:

1. create a custom statistic to count both CallConsult and CallInbound
2. create a custom filter on user-data keyword added by Softphone on transfer init
3. compare the results and let operation choose the better of two

Best regards,
Vic

[JTL]

[quote author=cavagnaro link=topic=2417.msg9695#msg9695 date=1192568504]
What about using KVPs?
An Inbound call without any of the KVP you have on your strategy may be a "consult" call (~(PairExists("myKVP","*")) or you can modify your softphone and add a KVP when doing a consult call (PairExists("KVPConsultMultisite","*"))

[/quote]

One of the biggest reasons for changing the transfer routing logic was to preserve the attached data from an inbound call when it was transfered (so the receiving agent gets correct screenpops etc).

So a consult call would have, unfortunately, all of the KVPs of an inbound call (and then some).

Your point about adding a KVP (from the Softphone) when making a Consult Call is a good one, and one that perhaps we can investigate.

Combined with Victor's response, we can almost certainly build a custom stat:

(N_INBOUND+N_CONSULT_RECEIVED)-(N_INBOUND{withKVP}+N_CONSULT_RECEIVED{withKVP})

Could probably simplify that, since N_CONSULT_RECEIVED should ALWAYS equal N_CONSULT_RECEIVED{withKVP} but I'd be happier to leave the extended calculation in there, if only to show the 'workings out'...