Dynamic agent queuing

[chad_meyer]

Hey everyone,

I have an interesting build I was tasked with and an open to suggestions.  A client we took over has a very unique contact center in which they potentially have 1200 "queues" assigned to an agent.  Obviously this is an administrative nightmare not to mention inefficient and an impossible feat to replicate in UCCE.  The call routing matches agents with company and state, hence the enormous amount of queues.  For example there will be queue ABC-AL, ABC-AK...and so on.  There is no consistency between agents and geographical ownership unfortunately.  

What I am interested in doing is setting up a DB dip that will look for agent/company/state to return a "1" and then through the agent API assign all matching entries to a queue.  Once the call ends or the user enters wrapup the system would then remove that attribute from the user (which I still need to figure out).  

Not sure if this is the best way to approach this design and would appreciate any feedback and guidance.

Chad

[david.macias]

Holy god! Are you saying that every call will look into a DB, you then get the skills that call needs. Then you will skill your agents with those skills?!? While possible I think you're going to run into a lot of issues. What happens if your agents have max attributes?  There's a limit to how many requests you can make to the Agent API (throttling). What happens if your backend is down?

My thinking is that they are using this method for reporting purposes so why not move all these skills to call types? Then just have actual skill (english, support, level 2) for agents and that way remove a lot of the complexity.

david

[chad_meyer]

Hi David,

Just saw this message so apologies for the delay.  Thank you for the response.  I am not really concerned with the database dip for each call.  We are doing that with other business units in our org and have not had any problems.  Good point on the API throttling and max requests.  

The reason for so many queues is because agents are trained for particular clients (matching criteria 1), along with a particular state (matching criteria 2).  You could have an agent trained on companyA in FL, GA, SC but not with the company in other states.

I am also looking for a way if we can take those matching DB entries and dynamically assign them to a SG.  The returned information would be companyA-FL and the DB would return a list of agents that match both companyA and FL but am finding difficulty on how that could be achieved, if at all possible.

[david.macias]

I had a very similar problem a few years back with an insurance company. Every agent was licensed only in specific states and from there they had specific specialties. At the end of the day the matrix of attributes an agent could have was something like 2000 different attributes. states (50), specialty (20), language (2). I don't recall what the ultimate solution was, but we were not able to solve for it like for like with Cisco.

If you had to go down this route this is what I would do.

- Build agent to attribute table. I would add proficiency since you might as well go all out.

- Build all PQs with state, company attributes.

- Build a tool which monitors the real time stats of each PQ. This might be tricky as you might have to find out a clever way to monitor all 1200 PQs at once.

- Queue your call to a PQ that has no agents.

- Check if an agent is logged in and programmatically add attributes and proficiency to agents based on calls in queue. Remove attributes of agents currently not in a call.

This is possible, but just a big undertaking. Specially ensuring that your agent table is up to date because if that is not updated then you will have PQs with no agents.

david

[chad_meyer]

Thanks David.  To clarify:

 -Build agent to attribute table. I would add proficiency since you might as well go all out.

Assuming you mean build it externally (ie...SQL?)

- Build a tool which monitors the real time stats of each PQ. This might be tricky as you might have to find out a clever way to monitor all 1200 PQs at once.

Would this be to ensure no queues have 0 agents assigned to them?

- Queue your call to a PQ that has no agents.

Can you please clarify?  This would not work as it would cause a requeryresult of 2.

- Check if an agent is logged in and programmatically add attributes and proficiency to agents based on calls in queue. Remove attributes of agents currently not in a call.

This is the main portion where I am struggling to come up with a solution.  Do you have any suggestions of where to start?

Appreciate the clarification.

Chad

[david.macias]

- Build a tool which monitors the real time stats of each PQ. This might be tricky as you might have to find out a clever way to monitor all 1200 PQs at once.

Would this be to ensure no queues have 0 agents assigned to them?

Yes, would have to be external.

- Queue your call to a PQ that has no agents.

Can you please clarify? This would not work as it would cause a requeryresult of 2.

Are you sure about that? Why can't you queue a call to an empty queue?

- Check if an agent is logged in and programmatically add attributes and proficiency to agents based on calls in queue. Remove attributes of agents currently not in a call.

This is the main portion where I am struggling to come up with a solution. Do you have any suggestions of where to start?

Good point, if you're running PCCE you might be in luck with the APIs if you're running UCCE you might be SOL. What are you running?

[chad_meyer]

Of course I am running UCCE 11.6 and I would have to double check on the requery status.  May just be getting confused on when I saw that come up.  Not sure why API behavior would be different between PCCE and UCCE.

[david.macias]

There are differences in the APIs between UCCE and PCCE. You're in luck the UCCE 11.6 API doc says that changing agent attributes is possible via the API. You will have to have Unfortunately you will have to have many "supervisors" changing attributes as the API only allows the supervisor of that team of agents to change attributes.

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/icm_enterprise/icm_enterprise_11_6_1/Program/Guide/ucce_b_developer-reference-11-6/ucce_b_cisco-unified-contact-center-enterprise_chapter_00.html#PCCE_RF_M76B1FFD_00__sec...

david

[chad_meyer]

Thanks David.  I am working on that now and of course the docs don't match the application experience.  I started another thread about the agent API issue I am experiencing located below:

https://community.cisco.com/t5/contact-center/agent-api-to-add-attributes-to-agents/td-p/4121863