[cisco-voip] UCCX script related questions

Tue Jun 20 11:19:30 EDT 2017

Yeah, I'm assuming that he might be thinking of hunt group logic and CCX as a way to add reporting into that, but the answer isn't as cut and dry

Ben Amick
Telecom Analyst

On Jun 20, 2017, at 9:31 AM, Brian Meade <bmeade90 at vt.edu<mailto:bmeade90 at vt.edu>> wrote:

Your requirements sound more like you just want to send calls to broadcast hunt groups rather than using UCCX queues/agents.

On Tue, Jun 20, 2017 at 12:16 AM, naresh rathore <nareh84 at hotmail.com<mailto:nareh84 at hotmail.com>> wrote:

is it possible to use broadcast algorithm in uccx?

________________________________
From: Bill Talley <btalley at gmail.com<mailto:btalley at gmail.com>>
Sent: Tuesday, June 20, 2017 6:05 AM
To: naresh rathore
Cc: Ben Amick; Terry Oakley; cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] UCCX script related questions

One thing to keep in mind about forcing an agent back to ready, if there is only one agent in a ready state and that agent misses a call, the system will continuously send the call to that agent.  The caller will NOT necessarily hear queue music/message oh hold and will never receiver any queue prompts with options to escape the queue (like zero out, leave vm, etc).  If that agent is away for 15 minutes, the caller will literally be ringing that one agents phone for the entire 15 minutes (assuming no other agents become available).

 Even if there are multiple agents in a ready state, if the call is routed to one agent who's not available to answer, you're subjecting the caller to a minimum 60s delay before the call will be routed to another available agent.

Supervisors have the ability to change agent states using their supervisor login.

Sent from a mobile device with very tiny touchscreen input keys. Please excude my typtos.

On Jun 19, 2017, at 7:45 PM, naresh rathore <nareh84 at hotmail.com<mailto:nareh84 at hotmail.com>> wrote:

i tried to explain manager about benefit of agent being in not ready state after he doesnt pick the call. but he is keen on automatically changing the state from not ready to ready state. is there an option to revert back to ready state from not ready state.

do the supervisor have to login using his credentials on appadmin page to get rights to change skills?

________________________________
From: Ben Amick <bamick at HumanArc.com<mailto:bamick at HumanArc.com>>
Sent: Monday, June 19, 2017 7:59 PM
To: Terry Oakley; 'naresh rathore'; cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: RE: UCCX script related questions

Regarding the last question: If a supervisor logs into the appadmin page, they will be given a dialogue that will enable them to change skills and skill levels.

As for skills vs skill based routing, etc. it’s a question of how you want to engineer it. Not ready on no-answer is only good if you have an environment where agents have to manage their status. Remember that when they are on a call they will be in the offhook or talking state, so you will not have to worry about them not answering calls, as they will not be presented.

As for the tiering with SBR, the question is how you want to prioritize calling. I’m assuming this is a helpdesk style structure, in which case I can understand segmenting apart calls.

However, I could see it done with multiple groups, with L3 engineers also being in the L1/2 queues but at a lower skill level and so on, but that’s just another option.

In general I would want L1 engineers to be given calls unless they’re completely unavailable and then given to L2 and then L3. You could accomplish this by checking qty of ready state in the queue as opposed to using timers.

This would also make it so that clients would not have to wait up to 180 sec before voicemail, and would be reactive to the number of ready agents, only escalating to l3 if all the L1/2 engineers are exhausted.

Also, managing ready state should be a function of HR/Supervisory, auto-setting back to ready would just cause it so that you’d have longer queue times.

You should be able to change the ring timer per user for timeout, but the longer you set it out the longer your queue times will be as it will be presented to less users. If you set it to 60sec, then in your design it will only ring 1 L1, 1 L2, and 1 L3 over a period of 180 sec.

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Terry Oakley
Sent: Monday, June 19, 2017 10:40 AM
To: 'naresh rathore' <nareh84 at hotmail.com<mailto:nareh84 at hotmail.com>>; cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] UCCX script related questions

I am not an expert in this at all but have some experience with a similar situation.    I would suggest, and am glad to be corrected by those that have more expertise, that you use skills based routing.   The skills can be adjusted by the supervisor on the fly so that leaves it to the supervisor to have the right staff (engineer) in place to respond to the call.    As for extending the timeout to being set to Not Ready I believe that can be adjusted on the Application Management section under agentTimeout.   Again very happy to be corrected as I am still working through scripting and how to make it the most efficient.

Terry

Terry Oakley

Telecommunications Coordinator | Information Technology Services

Red Deer College |100 College Blvd. | Box 5005 | Red Deer | Alberta | T4N 5H5

work (403) 342-3521   |  FAX (403) 343-4034<tel:(403)%20343-4034>

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of naresh rathore
Sent: June 19, 2017 1:48 AM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] UCCX script related questions

hi All,

i have to configure CRS scripting on UCCX. following is the requirement.

  1.  broadcast ring to level 1 engineer for 60 sec, then call goes to queue and plays the option to exit the queue and leave voicemail.

       2. if exit option is not selected, it will broadcast ring level 2 engineer for 60 sec, then call goes to queue and plays the option to exit the queue and leave voicemail.

       3. if exit option is not selected, it will broadcast ring level 3 engineer for 60 sec, then call goes to queue and plays the option to exit the queue.

       4.if exit option is not selected, it will go through step 1, 2, 3 and then go to voicemail.

I have following queries

       1. after 3 rings, the agent (finesse) because not ready. is it possible to extend the timeout to 60 second. is it possible via "select resource" step?

        2.because i have to go through step 1, 2, and 3. during first round when the state of the group is automatically changed to not ready (if nobody answers), is it possible to change the state automatically to ready after some time.

         3. Should i use resource group or skill based routing

         4. they also will be changing engineers from one level to another. is it possible to assign different skills /change skills of a user using supervisor desktop or limited version of appadmin page?

Thanks all

Regards

Naray

Confidentiality Note: This message is intended for use only by the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. Thank you
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip<http://cp.mcafee.com/d/2DRPoQrhod78UQsKfI3APtPqabbXaoUsyqejqabbXaoVVZASyyO-Y-euvsdEEK6zAQsTLt6VIxGIH5gkjrlS6NJOVICSHIdzrBPtZpjd7b1EVvW_9KcK6zBVzHTbFIzCeopvu76zC_khjmKCHtB7BgY-F6lK1FJ4SCrLRQkhPz0WXVEVdTdAVPmEBCbdSaY3ivNU6U9GX33VkDa3JsJaBGBPdpb6XiFqFsPmiNsxlK5LE2BCX5u1FfUY3jrbPbPxI5-Aq83iTqlblbCqOmdbFEw2oA90cq8amz9qpEwzV-PZ0Qg2PvQDaIa6S73taPy>

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip<http://cp.mcafee.com/d/2DRPoscy0wrhod78UQsKfI3APtPqabbXaoUsyqejqabbXaoVVZASyyO-Y-euvsdEEK6zAQsTLt6VIxGIH5gkjrlS6NJOVICSHIdzrBPtZpjd7b1EVvW_9KcK6zBVzHTbFIzCeopvu76zC_khjmKCHtB7BgY-F6lK1FJcSCrLRQkhPz0WXVEVdTdAVPmEBCbdSaY3ivNU6U9GX33VkDa3JsJaBGBPdpb6XiFqFsPmiNsxlK5LE2BCX5u1FfUY3jrbPbPxI5-Aq83iTqlblbCqOmdbFEw2oA90cq8amz9qpEwzV-PZ0Qg2PvQDaIa6S73rSOew5b_z8V>

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
http://cp.mcafee.com/d/2DRPowrhod78UQsKfI3APtPqabbXaoUsyqejqabbXaoVVZASyyO-Y-euvsdEEK6zAQsTLt6VIxGIH5gkjrlS6NJOVICSHIdzrBPtZpjd7b1EVvW_9KcK6zBVzHTbFIzCeopvu76zC_khjmKCHtB7BgY-F6lK1FJ4SyrLRQkhPz0WXVEVdTdAVPmEBCbdSaY3ivNU6U9GX33VkDa3JsJaBGBPdpb6XiFqFsPmiNsxlK5LE2BCX5u1FfUY3jrbPbPxI5-Aq83iTqlblbCqOmdbFEw2oA90cq8amz9qpEwzV-PZ0Qg2PvQDaIa6S73tHgppSas5t7x

Confidentiality Note: This message is intended for use only by the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. Thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20170620/2d418424/attachment.html>