UCCX Agent Indial

Answered Question
Jun 21st, 2010

Does anyone have an elegant way of providing UCCX agents with an indial service on their agent phones? Customer currently has the scenario where selected customers are given the agent's indial number to call directly, rather than going through the queue. They want to preserve this capability. A second line is not ideal since they also want to report on these calls from the UCCX reporting suite. I can see how we can do this with individual agent CSQs (only an handful of agents so scaleability is not an issue) however I'm not sure if this is the best way to go.

Thanks

Folks 

I have this problem too.
0 votes
Correct Answer by Jonathan Schulenberg about 6 years 5 months ago

Usually you can do it either way. I tend to go the single-script route more often than not. Here are a few thoughts in no particular order:

  • Reporting on the total quantity of calls is more likely to occur at the application level. You do have an advantage on a few of the reports if you create separate applications although some do allow filtering by trigger.  Take a look at the reports you want and understand which of them require application-level data to make this decision.
  • Each application loads a copy of the script into the Java heap. This is a limited resource so depending on the scale you are attempting to do this at you could run into problems. Each call (and other background processes) also consume this. There is no hard science to this, just keep an eye on it (perfmon counters were added in 7.0(1)SR4) and stress test the system if you end up creating a moderate/high volume of applications or scripts.
  • Most of the script and the general callflow will usually be the same for most agents so making a single script the most efficient path. Small things such as voicemail destination can be adjusted mid-script by updating variable values. For example, if the script should play two prompts differently per-person and change to a different voicemail destination, just use three Set steps within the matching Switch step condition.
  • Even if you create a single script, you can still assign it to separate applications if reporting needs dictate it. Keep in mind that this doesn't save you anything from a memory perspective as each application loads its own copy of the file into the heap; however, it gives you a single script to maintain.

Again, either path will likely work for you. The BU has generally avoided taking much of a "best practice" stance to avoid the massive debate that would doubtlessly ensue. Cisco is not well accustomed to having a product that includes an IDE. Everyone programs CCX differently because of this. There is a document on the topic but it's pretty light IMO.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Jonathan Schulenberg Tue, 06/22/2010 - 05:04

My suggestion is to do agent-based routing and fallback to the general CSQ if the agent is not available. This has the advantage of getting the customer connected to a live agent when they call the first time.

You would do this by creating a new application, assigning the indial [DID] numbers as triggers to this application, and then use a large Switch statement which contains a different condition for each of the DIDs. Each matching condition will have a Select Resource step that has the agent's username in it instead of a CSQ. This will offer the call to the agent if they are available. If they are already on the phone, the step will fail (no queue branch on agent-based routing). From there you can proceed to queue the caller against the CSQ for the department.

bruce.wilkinson Tue, 06/22/2010 - 17:58

Thanks Jonathon,

Thats pretty much what I though, although I was thinking of an application and script for each agent rather than the switch step. Less elegant perhaps but offers a bit more flexibility if they want different treatment between agents on no availability. voicemail or overflow for example.  Do you have one big script or lots of little ones. My approach oin the past has been for the latter. I'm not sure if there are any performance issues either way.

Cheers,

Bruce

Correct Answer
Jonathan Schulenberg Wed, 06/23/2010 - 04:55

Usually you can do it either way. I tend to go the single-script route more often than not. Here are a few thoughts in no particular order:

  • Reporting on the total quantity of calls is more likely to occur at the application level. You do have an advantage on a few of the reports if you create separate applications although some do allow filtering by trigger.  Take a look at the reports you want and understand which of them require application-level data to make this decision.
  • Each application loads a copy of the script into the Java heap. This is a limited resource so depending on the scale you are attempting to do this at you could run into problems. Each call (and other background processes) also consume this. There is no hard science to this, just keep an eye on it (perfmon counters were added in 7.0(1)SR4) and stress test the system if you end up creating a moderate/high volume of applications or scripts.
  • Most of the script and the general callflow will usually be the same for most agents so making a single script the most efficient path. Small things such as voicemail destination can be adjusted mid-script by updating variable values. For example, if the script should play two prompts differently per-person and change to a different voicemail destination, just use three Set steps within the matching Switch step condition.
  • Even if you create a single script, you can still assign it to separate applications if reporting needs dictate it. Keep in mind that this doesn't save you anything from a memory perspective as each application loads its own copy of the file into the heap; however, it gives you a single script to maintain.

Again, either path will likely work for you. The BU has generally avoided taking much of a "best practice" stance to avoid the massive debate that would doubtlessly ensue. Cisco is not well accustomed to having a product that includes an IDE. Everyone programs CCX differently because of this. There is a document on the topic but it's pretty light IMO.

Actions

This Discussion