Currently in process on a BA and Design for a UCCX solution that is intended to replace an existing ACD system with hundreds of unique queues. The current approach essentially implements a 1-to-1 mapping for each named customer to a queue with unique group of agents based on line of business familiarity. Those agents and ONLY those agents are the first choice for call routing. While it's always been our approach to streamline and effectively use CSQs to more efficiently leverage available resources with more generic CSQs and Skills based routing, the current approach is foundational to the business model and cannot be completely overhauled day1.
The maximum CSQ limitation given our platform is 150 and insufficient to support the current 1-to-1 LoB approach even if scaled back. Given the assumption that we can identify resources (by userid or extension), skills or CSQ required based on the incoming called number:
Is there anyone that has encountered a similar scenario and can suggest an alternative approach to resource selection that would ensure that a group of defined resources with line of business familiarity are the primary choice for call distribution? NOTE: It is acceptable to overflow to a more generic skills based CSQ with no customer familiarity in the event that no resource is available from the first choice pool.
I have considered how Agent-Based routing might be leveraged here, but it seems like a good deal of administrative overhead would be involved to attempt to check availability in successive order of individual named agents derived from a DB Dip. It certainly doesn't seem ideal.
Any suggestions are welcome as the alternative is to conclude that it is simiply not possible to accomodate the current requirement.
You're not going to find a solution which doesn't involve a lot of overhead. You could build some some of DB lookup that based on certain parameters decides what agent to go after, however you're getting stuck into a never ending spiral. Your best bet is to try and minimize some of the CSQs maybe by combining some of them. This will be the easiest and cheapest route to take.
Thanks for your feedback David. I concur that the implementation needs to be scaled down through operational process refinement. Unfortunately I still have a day 1 requirement that isn't going anywhere, so it may be that the added complexity of a db driven agent-based routing methodology is the only way to achieve in the short term.
You don't say how many agents you have but if its less then 150 then I would create a CSQ for each agent based on their name.
When the call comes into the CCX script do a db lookup based on the original dialed number to return a list of agents to handle this call. Sit in a loop doing a select resource step to add in these agents CSQ's with possibly a 1 second delay.
You would want an overflow CSQ in case your db lookup did not return any results.
One simple script with one route point to handle thousands of numbers. Don't use a translate pattern to send the calls to the route point as this overwrites the original dialed number.
Of course you are going to have to write a program that will allow the customer to setup and maintain the db table.
Keep your CCX scripting simple and do the hard work outside.
The lowest ceiling is actually how many CSQs you can assign an individual agent to: 25, not 150. The 150 number is the total quantity system-wide, including voice, email, and chat since there is no multi-channel support in CCX.
I had a similar situation where there was a large quantity of customers but ultimately they routed to only a dozen or so pools of real agents. The limitation was mainly a reporting and billing issue, not a call routing problem in my case. I solved it by writing unique customer IDs to the peripheral variables. We had the customer's Crystal expert write custom reports for the HRC that filtered by the peripheral call variable to get the reports per-customer.
If you actually have that many different groups of people and are set on CCX multiple clusters is probably your only option. You can integrate more than one CCX cluster with a single CUCM cluster. Just note that all reporting/queuing/etc logic cannot be extended beyond each CCX cluster (without ICM). Each CCX cluster is it's own island.
I'm not a CCE engineer but the new Precision Routing feature may also be an option since it allows you to work in a less lineral thought process when creating skills. I'm uncertain what type of restrictions/ceilings exist there though; a CCE guru would need to chime in.
I had a somewhat similar requirement in a recent UCCX implementation. My suggestion would be to create different customer service teams. Then you assign each customer to a team, and build a CSQ per team. It isn't quite as granular as the one to one method you describe, but I imagine there is a fair amount of overlap where a particular set of agents handles multiple customers. Each customer service team would be a skill/CSQ. You will need to store that customer to team mapping in a database or in the document store.
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.