Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Work/Wrapup Timer in CCC not clearing

Status
Not open for further replies.

Biscuits87

Technical User
Sep 18, 2011
43
GB
I have a question regarding prairieFyre CCC when running an agent state by time, this issue is only effecting one path.

Site is running CIS: 6.0.11011.1
MCD: 5.0 PR1 (I know)

I've checked the pF KB for fix packs. None of the fixes listed pertain to this issue.

[ul]
[li]Calls come in on a dummy HG which has a call forward set to NPM.[/li]
[li]NPM Call Director then handles the call, eventually the call is passed to an ACD path with a primary and overflow agent group (AG).[/li]
[li]Once the call has ended the agent should enter wrapup for 30 seconds. However, when a call has finished on this path (P166) the agent will remain in wrapup until they are manually removed.[/li]
[li]This happens when members no matter if a primary or overflow agent group takes the call.[/li]
[li]The overflow agent group is also a member of other paths, when agents take calls for those paths their work timer only lasts for 30 seconds as it should.[/li]
[liThe CoS Work Timer is set to 30 seconds. All agents have the same CoS.[/li]
[/ul]

I have inspected the raw ACD data. When they get stuck the trace looks as such:

Code:
93G124833P166   258    00
95K12483510600000500000000000
99L124902258    258    00
--j124900258    258    -3127.0.0.1       Software WKT    
01M124902258    258    00
02E124902258    258    00
03E124902258    258    00
51F125228258    258    00

Whereas a working call:

Code:
19G131823P151   210    00
25L131900210    210    00
32M131929210    210    00

As you can see when the agent gets stuck in wrapup there is a MiTAI generated event (--j) as soon as the work timer is set (L event). This event is (According to my notes): "MiTAI Agent Set Make Busy with reason code Request". The work timer is then removed (M event) and then set again (E event), twice. The F event is where I had to manually remove the work timer.

The working call on a different path looks fine. Agent takes the call, work timer is set then removed. Nice and simple. I've put the paths side by side and the settings look the same, not that I can see any that would effect the work timer. I've checked NPM, checked CCM... I'm missing something I know. I'm not sure what though.

Any help would be greatly appreciated.
 
Have a look at the phone when it is in work timer and ensure it says work timer on the display.
You dont say what version of CCM you have but the latest release has an option to put the Agent in Work Timer for up to two hours, However it actually puts the agent in Make Busy with a reason code of Work Timer. Therefore if it is the CCM that is putting it in Work Timer you only see Make Busy on the Phone and not Work Timer.
The settings for this are against the Path in YSE.
 
They're running v 6.0 as listed at the top.
I had a look for the settings on YSE but couldn't see it. I have some make busy codes of -3, -2 and -1.. With names that relate to what could be going on. Do you think that could be the issue? They were created by the install.

Will have to contact site and ask what's being shown on the screen. Thanks.
 
The phone is showing Make Busy.

So I decided to use my eyes... Found the column in YSE haha.
Unfortunately it's blank, which lead me to believe that the options was turned off.

I went into SQL and looked at the table for the queues (dbo.tblConfig_Queue).
Under the column "IsWrapUpTimeEnabled" it had a 1 set against it. Every other queue was set to 0. So I changed my path to 0. After testing it's still doing the same thing. I was always under the impression that changes to SQL were in real time as it's the database... I don't have to wait longer for the change to take place, do I?
 
Also the only other difference I can see is that the queue was created by the _admin user. The others were created during the install.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top