Calls not being presented, "stuck" in queue

[dmacmart]

My client has a Symposium system with somewhat complex scripting. They have asked me for help with what seems to be a bug with transferred calls.

Under certain circumstances, I see that there are idle agents in a skillset and a call waiting in that skillset. It does not get presented to any of those agents. This seems to happen when all agents have been idle for a period of time, perhaps 4 minutes. If a new agent becomes available, or an idle one makes him/herself Busy then Available, the call will immediately be offered. And other times, a call will be offered, but not to the longest available agent.

If a new call arrives (not a transfer) and is assigned to that skillset, it is offered immediately to the longest available agent as expected.

So my question is where should we look? What might be the problem? Is there maybe a disparity between the parameters set on the call, agents, skillset, CDN that is causing confusion for the waiting call? Our eyes have not seen anything obvious after a couple days' search.

Thanks!

 

[Milesprower]

You need to look to see that the system is updated to the latest patches an is in compliance with the Nortel hotfix compatibility matrix.

Since you say it is Symposium (not Contact Center Manager) then I would assume you are out of luck as Nortel no longer supports Symposium.

 

[sandyml]

It's really tough to say, without any specific information. You mention that the scripting is rather complex - can you post an example?

Also -- is there any networking going on between sites? Longest idle agent commands in the scripting?

 

[captaingadget]

Maybe the break timer in the call presentation class is set too long?? Also, in the master script make sure there is sufficient time for a transferred call to complete the transfer before executing a script e.g.

IF TRANSFERRED THEN
WAIT 6
END IF

 

[dmacmart]

captaingadget - We normally have a WAIT 2 because we have a 3.3 second answer requirement. Would WAIT 6 add 6 seconds to our answer time?

sandyml - below are the salient bits of code so you can see what our client is doing.

milesprower - we are using Symposium and know it's not supported. But we are wondering how we could have screwed up such a simple requirement.

Thanks to all for your help.

Note that we do see that the call is queued to the P_ZZ_AG_CC_EN_SK skillset, but an agent will not get it if they are idle for more than X seconds. New (not transferred) calls can also arrive and be assigned to that skillset and get answered right away. The script that handles these is identical except it does not assign high priority but MEDIUM. (P_HIGH_PRIORITY_GV is 2, LOW is 6 and MEDIUM is 3)

In the master script: (CDN 6033 is one giving us trouble)
======================================================================
...
IF CDN = P_ZZ_xfer_cdns THEN
WHERE CDN EQUALS
...
VALUE 6033 : /*ENGLISH CC*/ EXECUTE SCRIPT P_ZZ_XFER_CC_EN
...
DEFAULT : ROUTE CALL DEFAULT DN
END WHERE
END IF
...
======================================================================
/* The total P_ZZ_XFER_CC_EN script: */

/*Handling the abandon event in SCCS storing the call arrival time on the DB*/

EVENT HANDLER
EVENT CALL ABANDON:
IF P_HDX_ON_GV THEN
SEND INFO P_HDX_ID_GV CDN, DNIS, CLID, P_HDX_ABANDONED_MSG_GV
END IF
END HANDLER

ASSIGN P_HIGH_PRIORITY_GV TO P_current_call_priority_cv

IF NOT OUT OF SERVICE P_ZZ_AG_CC_EN_SK THEN
QUEUE TO SKILLSET P_ZZ_AG_CC_EN_SK
BY LONGEST IDLE AGENT
WITH PRIORITY P_current_call_priority_cv
WAIT 2
END IF


IF NOT QUEUED THEN ROUTE CALL P_ZZ_DEFAULT_ACD END IF

 

[captaingadget]

In answer to your question, yes the 6 seconds will be added to the answer delay time. In SCCS 5 all time spent in the master script is is added to the time in the primary. This is not the case in CC6.

Regarding your problem, lets just be clear, you are making a call to CDN 6033 and are looking at the RTD for the SKILLSET and seeing it queue for this skillset when there are idle agents? New calls not on 6033 get answered OK and they use the same primary script?

Do the 6033 calls EVER get answered?

If the above is an accurate desciption then I would be tempted to look at the config of the CDN. Maybe de-acquire it and re-acquire it. Just a small point, there is no need to specify BY LONGEST IDLE AGENT when queueing to only one skillset, it is only relevant when you queue to more than one.

 

[dmacmart]

captaingadget, yes this is an accurate description of the problem. The calls that queue will only be offered to agents who become newly available (either on call that ends, or make themselves busy/available). Newly arrived calls - not transfers - do get offered right away. An additional point to note, calls are offered to agents who are not the longest available.

We will try to deacquire/reacquire the CDN on offpeak hours as well.

(Our client is using SCCS 4.2 - long beyond the supported timeframe but it's worked thus far for them, other than this anomaly)

 

[captaingadget]

This is sounding weirder by the minute. Usually problems that defy all logic turn out to be a software screw up. So try de and re-acquiring the CDN, if that does not clear the problem (which it probably wont) I would build a new skillset and put all the agents into it so they are now in the original and new, then change the script to queue to the new skillset. If that does not clear the problem restart the server. If that doesn't clear it I guess you are looking at deleting and rebuilding stuff.

Any other ideas anybody??

 

[Milesprower]

From my experience you are wasting your time playing around with scripting and configuration. You need to make sure you have a clean implementation with all applicable patches (and nothing else). Funny things can happen when non-approved Nortel updates or third party applications are applied.

The core directive of the SCCS programming is to deliver calls to the highest ranked, longest idle agent. You can override this directive through bizarre configuration changes, but that does not appear to be the case here.

 

[sandyml]

Given that this is an older release, I have what may seem to be a strange question:

Does this tend to happen when all agents are on a call, and then it never gets delivered once an agent becomes idle? I remember a similar problem using the "longest idle agent" statement awhile back. Something about it only looking to see who was idle initially, but never checking again.

If so, try eliminating the "longest idle agent" statement or add another "queue to" statement, like:

IF NOT OUT OF SERVICE P_ZZ_AG_CC_EN_SK THEN
QUEUE TO SKILLSET P_ZZ_AG_CC_EN_SK
BY LONGEST IDLE AGENT
WITH PRIORITY P_current_call_priority_cv
WAIT 2
QUEUE TO SKILLSET P_ZZ_AG_CC_EN_SK
WAIT 2
END IF

 

[dmacmart]

sandymil: We tested this and it's the opposite. When an agent becomes idle, they get the call immediately and much-longer-available (4 minutes, perhaps) don't get offered the call. But maybe I'll suggest they remove that directive since it has no effect in this case.

captaingadget: After your comment (about highest-ranking), we examined the agents, and they had different priorities assigned to the skillsets. So that could explain why the call does not get offered to the longest-available. It doesn't, however, explain why a call doesn't get offered.

 

[sandyml]

I believe it's already been suggested, but have you made sure that the PBX has the most recent patches? And that the SCCS server also? I know that SCCS patches would be hard to come by since it's no longer supported. But it does sounds as though there is a problem with status messaging going stale.