Interflow...Is it any good?...

[Drisk]

We have a normal ACD V8.x are looking at using interflow steps betweem to call centres that has the telephony going externally (no QSIG, DPNSS. We have a WAN data connection but I think the firewall will be problematic.

My questions are :

1. Is interflow any good what problems have people encountered?

2. How does it work? I.e. does it check if an analyst is available by taking across the Data network or voice?

Any help regarding this will be greatly appreciated.

 

[Moebius01]

The first question would be are you thinking of Interflow or Network Interqueue?

With Interflow, there is no look ahead to the other call center for available agents, and no signalling. In effect, it's a trunk to trunk transfer between switches.

Interqueue on the other hand sounds more like what you're wanting. It uses the d channel for signalling, and in effect, a call could be queued between two or more callcenters simultaneously.

We've used both fairly successfully. The biggest challenges really come around 1) making sure the CCTs are clean and correct, and the big 2) reporting. Getting truly accurate numbers requires some thorough custom reporting.

 

[Drisk]

Thanks Mobeius I am definitely talking interflow as we cannot do interqueue due our setup. Aspect say we cannot use it because we have different Service Providers.

So with interflow what is the difference between this and doing a dial out step combined with IF statements?

 

[Drisk]

...At present I have created a solution which Dials across both sites where the call is grabbed across. Normally I do this where the call is not grabbed (by having no anouncements just agents and wait on a loop) and so on a dial out it will queue on both sites until an agent is available on either site.

However on this particular case I cannot Queue on both sites as it will take up too many trunks and so instead I am dialling the call to the other site and jumping the call across to the second site. This is not ideal but as it is only required for a month it is the best known mehod available.

A suggestion has been made that using interflow would be better than doing a dial out step. I personally am nervous to do this as I remember being told on more than one occasion not to touch interflow and instead dial the call. I have looked at all the known documentation Aspect have on interflow and I am still confused how it works.

Any help would greatly be appreciated

 

[Moebius01]

If you have Ts between the two switches, Interflow is ok. I'm not sure if either is a big advantage over the other, however. In effect Interflow just handles some of the dial out stuff automatically.

Here's one very off the wall question. Do you have Contact Server in place at either site?

 

[700503]

Moebius01,

Sorry to jump in. But I really have question as below.

Refer to the second problem 'Reporting' for interflow, do u have any suggested solution for it????

Many Thanks

Samuel

 

[Moebius01]

We did a pretty big white paper research of the effects of Interflow/Interqueue on reporting, but that was a while back.

Off the top of my head:
I seem to remember that each time a call is attempted to interflow to the second switch, it triggers an offered call.
If a call abandons between centers it will show abandoned at both.
There are a few added dispositions and call_types to look for.

Unfortunately, the best advice I can offer in this case is to set up a couple of test ccts between two switches and see what kind of data various scenarios generate.

 

[chris13]

as moebius already said: reporting must be implemented _before_ you go into production.
I'm in the funny situation to deal with Interqueue, IP-Interqueue and additional dialouts to 2 other sites...

local site:
outgoing NIQ-call has disposition 6 if answered at other site, to_node contains node-number of dest.-site

remote site:
offered NIQ-call is type 15 (or 16=short).
look at the dispositions 21,22,24,25 for abandoned calls.

hint reporting on IP-NIQ: if your reports are based on DDIs and you use DDIs on your virt.trunk-group which don't exist on the physical trunk-group where the calls come in, you'll have to use a outer-join between dnis.grp_num and calldetail.orig_grp. I was not very amused to get empty reports

there are many details to look at, which are not on my mind now. But feel free to ask

 

[700503]

Thanks Chris13 and Moebius01. We have interflow setting and I have checked 2 messages recorded in Call Detail table in each ACD. Seems there is no any relationship between these messages. So it is hard to calclulate the queue time as these 2 messages should be counted as 1 but the queue time in each ACD should added as 1. Any hints about what I can do now.

Thanks again!

 

[chris13]

oups, sorry: the outgoing niq-call at the local site and the offered niq-call at the remote have should have the same track-number.

we queue first at local site, then put it in the remote queue, too.

local site:
queue_time counts for full queue_time until call is answered at either site.

remote site:
network_time contains the queue_time of the call at the local site, _before_ it was offered to the remote site.
queue_time either the full queue_time or the queue_time at remote site only, I'll have to ask the admin at our remote site (other company -> no acess). or take a stopwatch

 

[700503]

Chris13,

Thanks you so much!

Track Number.............This is the interesting part....I though they had the same track number. Unfortunately, they are not same. That is why I can't relate those records.

For interqueue, yes it is as what u say. However, I get problem if it is interflow (trunk to trunk). I can't find any relationship between the record in two ACDs.

Any other hint?????


Thanks

 

[chris13]

Never used interflow. Without any signaling you'll have to look at the trunk-groups or DNIS from which the calls come in at the remote site. perhaps you can use CLI/ANI?

 

[700503]

Yes agree not to use the interflow...............but I am only to do reporting. For call flow, I dun have right to speak...........

As I am new to call center stuff, can u tell me more about CLI/ANI?


Thanks

 

[Moebius01]

ANI = Automatic Number Identification
CLI = Caller Line Identification

Basically caller ID. This is what the switch uses to grab (if available) the number calling in. If memory serves, CLI is basically the UK equivelant to ANI. It's not a 100% guarantee, and must be activiated by your provider and all, but it might help out. Basically, whoever programs the switch would need to add a step to stick the DNIS digits in a variable, which should transfer between the switches.

The idea would be to use that as a semi-unique identifier to pair up call records between the two switches.

 

[700503]

Thanks you very much.

I will check with my colleagues.