Call not routing to longest idle agent 3

[monkeybarfan]

Hi,guys

I had reports that a supervisor was watching the standard agent display in RTD's and that calls were not going through to the longest idle agents and that people were receiving calls when they were not ready for them*. I have used Crystal Reports to check the data and have the following findings:-

This is what has happened, chronologically...

12:35:38 - T Needham presented with call (Site B)
12:41:09 - H Rees presented with call (Site A)
12:47:58 - H Rees finished call
12:47:59 - H Rees went Not Ready
12:48:50 - T Needham finished call
12:48:50 - T Needham went Not Ready
12:50:10 - H Rees went Ready
12:51:35 - T Needham went Ready
12:51:36 - New call presented to T Needham (Site B)

I have no idea why the call went to T Needham instead of H Rees. The skillset priorities of these agents are identical and I am 99.99% sure that has always been the same.

The global setting on Symposium is set to "Longest time in idle status since last status change".

We use all network skillsets and the properties of all the network skillsets are set to "longest idle agent".

The only other thing I can think of is that it is something to do with calls travelling across the network between the 2 sites, but I don't really know how that works. Most of the other problems that get reported are due to the way this is set up.

Are there any possible explanations I can give to appease a few people here?

I have read some other threads and they say things like "if an agent lifts the handset and presses a digit that will reset their timer" but this would also reset them back to 0:00 on the standard agent display, wouldn't it? I know that was being watched at the time so they would have spotted that.

*...I have told them to communicate to staff, in any case, that it is standard call centre practice to make sure you are not ready to receive a call when you don't actually want one!!

 

[sandyml]

In one call center I know of, agents would press an autodial or speed dial button to reset their idle time. That does not show up on the display...

 

[Milesprower]

In a network environment, there are many more variables (like communication timeouts) that come into play. It is almost impossible to follow each call through.
That said, you should change call preference to longest idle since last cdn/acd call. Agents can do many things to affect their state and they don't always show up on the display (which is a snapshot).
Also make sure everything else is exactly the same at each site (timers,preferences,call presentation classes, etc.)

 

[DancingDave]

We don't have networked Symposiums (Symposia?), however, as I understand it, Symposium will seek to get a call answered by a local agent initially, even if there is another agent on a second site who has been waiting longer.

Only if there are no agents free will the call be offered to other sites?

Where was the call originally presented?

DD

 

[monkeybarfan]

Hi Milesprower

You talk about call presentation classes and the like.

all our agents have the same call presentation class - I assume only one was set up when the system was installed (before my time). However, one each of the two servers, they are set as follows

Site A
Presentation Option - Call Force Delay
* Call Force Delay Timer - 3
Return to Queue Wait Interval - 1
Return to Queue Mode - N/A
After Call, Break For N Seconds - 2
Answer By Placing DN Call On Hold - Unticked
* Agent Reserved for Network Call - Unticked

Site B
Presentation Option - Call Force Delay
* Call Force Delay Timer - 2
Return to Queue Wait Interval - 1
Return to Queue Mode - N/A
After Call, Break For N Seconds - 2
Answer By Placing DN Call On Hold - Unticked
* Agent Reserved for Network Call - Ticked

Obviously the * means there is a difference. the CF delay timer doesn't seem alarming, but should the Agent Reserved for Network Call be the same on both servers?

For further info - all calls come in through one server now (Site A), but agents in Site B actually log into the Site B server and calls are sent to them from the Site A server. (Idon't totally understand - I'm a Data Analyst with a background in Business Analysis - some of this stuff just landed on me!)

 

[Milesprower]

Well, the call force delay is normally zero unless there is a need to slow down call presentation. In the olden days, CTI applications sometimes needed a little extra time to catch up with the call. These days that is rare.

What do you mean by return to queue wait interval? In a call forcing scenario, the call is forced on the agent. There is not an opportunity to return an unanswered call (so the return to queue is 0).

You should have at least 2 seconds break time (as you do) in a forcing environment so the agent has enough time to get into Not Ready or log off before the next call is presented. Some might argue to lengthen the break time to 4 seconds.

Thanks for the extra information on the network topology. This brings up a large factor: What type of Network Skills Based Routing (NSBR) are you using? The original flavor Nortel introduced with Release 3 software or Local Node Inclusion (LNI) that was introduced with later software?

In your scenario (two sites connected by tie-lines with all calls incoming to one site), you will not be able to uniformly distribute calls across a network skillset unless you are using the LNI flavor of Networking.

 

[bryanata]

QUEUE TO SKILLSET [<skillset> | <list_of_skillsets>] BY LONGEST
IDLE AGENT {WITH PRIORITY <priority>}


I recently had the same problem and discovered this little hidden Gem in the Docs. page 199 of 630 M1_Scripting_June2004.pdf


Hope this helps it worked for me.

 

[sandyml]

Good point, bryanata. I learned this the hard way also. .

 

[monkeybarfan]

I'll try that Bryanata, thanks.

Milesprower, I didn't understand all that networking stuff you wrote, but I am not (supposed to be) on the technical side of things. However, in the config > skillset section, we have a last column called "Include Local Node", which can be checked or unchecked. Does that help or am I barking up the wrong tree?

 

[Milesprower]

You are in the right spot, but don't change anything!

If the LNI box is not checked, then, for sure calls will not be distributed evenly accross both of your sites. The system will queue up to agents on one site before looking at agents at the other site.

There are scripting changes that must go along with the LNI function. So, you will need to get scripting resources involved before making any changes.

If the LNI box is checked, you should dig further. Look on the Network Control Center (NCC) server. Check that network skillsets are configured for Longest Idle Agent.

 

[monkeybarfan]

Include Local Node is ticked for every skillset on both servers and all Network Skillsets have the Networking Method set to Longest Idle Agent.

I really appreciate all your replies, guys.

Bryanata, where can I find that document you referenced?

 

[bryanata]

Symposium call center server 5.0 doccumentation cd rom , english, M1 npts,M1_Scripting_June2004.pdf is where I found the information.

 

[Milesprower]

Ok, LNI is set up. Next step would be to look at the scripts themselves. There should be one queue command (LNI example):
QUEUE TO NETWORK SKILLSET xxxx
WAIT 2

Not two commands (Non-LNI example):
QUEUE TO SKILLSET xxxx
WAIT 2
QUEUE TO NETWORK SKILLSET xxxx
WAIT 2

Also check the skillset call presentation tab and make sure that the Call Source preference is set to None.

If these are set up correctly, then you are back to the Call Presenation class issue (they should be identical at each site).

If that checks out, then you need to start looking at the communication (LAN) and the T-spans between the servers.

If there are comminication or trunking issues, it will skew call distribution. Look for alarms in the alarm monitor or event browser and skillset and site filtering in the Network Communications Parameters.

 

[monkeybarfan]

OK, all our scripting is like the first example you gave and all the Call Source Preferences are None.

I'll have a look at the other things you mention, probably in conjunction with the IT department.

Cheers.

 

[monkeybarfan]

Bryanata, that script does not work with NETWORK SKILLSET, it only works with non-network skillsets