tool or report for tracing flow of call from CSQ to agent

[tato386]

We are running UCCX 12.5 and occasionally we get calls that *seem* to be routed to the wrong agent.  Basically, we're looking for a way to figure out why a particular agent was selected.  What was status of other agents?  What script action was involved? What skill levels were available, etc.  Most of the reports I see seem to be focused on agent or team performance over a length of time which doesn't seem to be helpful for this type of query.  I am not even sure a CDR log will help either.  It would be ideal if there was some way to see a snapshot of agent status and skills when a call came in.  Any suggestions?  Thanks

[Elliot Dierksen]

I don't know that CCX logs those decisions. Other than direct transfer to an agent, I can't think of an easy way that the script could influence the agent selection. That is determined by how the CSQ is configured. What is that is making you think the wrong agent is getting selected? Would you please elaborate on how the CSQ's are configured, how many agents are normally working, and a rough idea of your call volume?

[tato386]

@Elliot Dierksen this is a bit of a he said, she said type scenario.  We have a CSQ that is handled by about a dozen agents. 10 of these agents have a higher skill level and are the "front line" agents.  The other 2 have lower skill levels and are supposed to be selected only if front line agents are talking, not ready, not logged in, etc.    What happens is that once in a while the backup guys get rung and they say it should not have happened because there were front line guys in "ready" mode.

I look at reports for front line and I see ready times, not ready times, talk times etc. and it looks like these guys are working and taking breaks in what appears to be fairly normal patterns.  I tell backup guys that they got those calls because at that specific moment there were no front line agents ready but they don't believe me and insinuate the system is misconfigured.

That's why I am looking for some kind of "snaphsot" of all agent statuses for a particular CSQ when a call comes in which would help prove the system is working as designed.  

[Elliot Dierksen]

@bill.king1 makes a valid point about how you could do it using separate skills. I am inferring from what you say that the CSQ is configured to prefer the most skilled agent. The most skilled part only comes into play if there is more than 1 agent available. If only 1 agent is available, they get the call, period.

You could have a second CSQ which could be defined with a backup skill or make the minimum skill level of 5 in the primary CSQ and minimum skill level of 1 in the backup CSQ. Then you could put an additional select agent step at the bottom of the queue loop to the backup CSQ. A call can be queued to multiple CSQ's at the same time, but I have rarely done this because of the way it impacts reporting. A call that was queued to 2 CSQ would make it look like you had more calls. For whichever CSQ didn't get the call, that call would be listed as a dequeue.

The key thing you have to decide if you have two tiers of agents is how quickly the calls goes to the second tier. If you want the calls to go to the second tier immediately, the way you have it configured is how to do that. If you want there to be a delay before going to the second tier, you will need another CSQ.

[tato386]

@Elliot Dierksen I appreciate you trying to find a solution, but my point is I believe that the CSQ is working correctly as designed and doesn't need to be modified.  When the backup agents (with lower skill) get the call, it is because none of the higher skill agents are available.  This is exactly what management has requested and how it is working.  My problem is that the backup agents (who don't want to be bothered with these calls) doubt that there were no higher skilled agents available and speculate that the CSQ and agent accounts are somehow misconfigured.  I need to confirm and/or prove to the backup agents that there truly were no higher skill agents available at the time they get these calls.  If I can prove that then I can tell them to take their complaints to management to higher more front line agents rather than to blame me for not having the system configured correctly.   

[bill.king1]

So that's why I mentioned writing that data into the Peripheral Variables. Heck, you could even make it directed to these backup agents with the variable being "No_Primary_Agent_Avail" or something along those lines, so that it is clear to all involved why they got the call.
I found this step by step guide on how you might do that, if it helps. https://www.cisco.com/c/en/us/support/docs/customer-collaboration/unified-contact-center-express/212485-configure-uccx-to-show-options-selected.html

[tato386]

@bill.king1 it seems like that technique is geared towards capturing and displaying caller input in an IVR type scenario but unfortunately, we are not using IVR menus.  The script we use for this CSQ simply plays a greeting and then either immediately transfers the caller to an available agent or puts callers in a hold queue until an agent becomes available.

I am not necessarily looking for an elegant solution.  This is more of a one-off, POC type thing.  I wouldn't mind temporarily turning on some debug or tracing for the CCX CSQ engine that would show what the agent statuses are at time of call and why it decided to send call to a particular agent.  

[bill.king1]

Right @tato386 , but what I'm saying is you could do something similar, write a value in the Variables for the conditions of those CSQ(s) so that it will be written/available to you as "proof".

[tato386]

 @bill.king1 if the complaints continue to come up, I might just have to do that.  thanks

[bill.king1]

We once had this request from a CCE customer and what we did is use one of the Peripheral Variables to write in the conditions of the agents that were considered before routing to them (i.e. basically something like SkillA_1Avail2Logged;Skill2_4Avail10Logged) so that they could look at it historically. It shouldn't be needed, but in that case it gave them piece of mind.

[Elliot Dierksen]

If it is going to be anywhere in CCX, it will be in the ContactCallDetail table.

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_12_5/reference/guide/uccx_b_125db-schema-guide/uccx_b_125db-schema-guide_chapter_01.html#reference_23B7381ACF968A55883AA7C03DFDDC52