Re: [cisco-voip] UCCX script related questions

[Bill Talley]

No.

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

> On Jun 19, 2017, at 11:16 PM, naresh rathore  wrote:
> 
> is it possible to use broadcast algorithm in uccx?
> 
> 
> 
> From: Bill Talley 
> Sent: Tuesday, June 20, 2017 6:05 AM
> To: naresh rathore
> Cc: Ben Amick; Terry Oakley; cisco-voip@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  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 
>> Sent: Monday, June 19, 2017 7:59 PM
>> To: Terry Oakley; 'naresh rathore'; cisco-voip@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-boun...@puck.nether.net] On Behalf Of 
>> Terry Oakley
>> Sent: Monday, June 19, 2017 10:40 AM
>> To: 'naresh rathore' ; cisco-voip@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 

Re: [cisco-voip] UCCX script related questions

[naresh rathore]

is it possible to use broadcast algorithm in uccx?



From: Bill Talley 
Sent: Tuesday, June 20, 2017 6:05 AM
To: naresh rathore
Cc: Ben Amick; Terry Oakley; cisco-voip@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 
> 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 >
Sent: Monday, June 19, 2017 7:59 PM
To: Terry Oakley; 'naresh rathore'; 
cisco-voip@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-boun...@puck.nether.net] On Behalf Of Terry 
Oakley
Sent: Monday, June 19, 2017 10:40 AM
To: 'naresh rathore' >; 
cisco-voip@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







From: cisco-voip 

Re: [cisco-voip] UCCX script related questions

[Bill Talley]

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  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 
> Sent: Monday, June 19, 2017 7:59 PM
> To: Terry Oakley; 'naresh rathore'; cisco-voip@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-boun...@puck.nether.net] On Behalf Of 
> Terry Oakley
> Sent: Monday, June 19, 2017 10:40 AM
> To: 'naresh rathore' ; cisco-voip@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
>  
>  
>  
> From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
> naresh rathore
> Sent: June 19, 2017 1:48 AM
> To: cisco-voip@puck.nether.net
> Subject: [cisco-voip] UCCX script related questions
>  
> hi All,
>  
>  
> i have to configure CRS scripting on UCCX. following is the requirement.
> broadcast ring to level 1 engineer for 60 sec, then call goes to queue and 
> 

Re: [cisco-voip] UCCX script related questions

[naresh rathore]

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 
Sent: Monday, June 19, 2017 7:59 PM
To: Terry Oakley; 'naresh rathore'; cisco-voip@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-boun...@puck.nether.net] On Behalf Of Terry 
Oakley
Sent: Monday, June 19, 2017 10:40 AM
To: 'naresh rathore' ; cisco-voip@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







From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
naresh rathore
Sent: June 19, 2017 1:48 AM
To: cisco-voip@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 

Re: [cisco-voip] UCCX 11.5(1)SU1 released

[Abhiram Kramadhati (akramadh)]

Justin, can you unicast the install/upgrade logs from any of these clusters? 
The defect you are referring to is fixed in 11.5, so that code should not even 
be affecting SU1 unless there was a step upgrade involving 11.5(1). collecting 
the logs now should still be okay, hopefully they haven’t been overwritten.

@Anthony – thanks, appreciate it!

Regards,
Abhiram Kramadhati
Technical Solutions Manager, CCBU
CCIE Collaboration # 40065

From: Justin Steinberg 
Date: Tuesday, 20 June 2017 at 5:29 AM
To: Anthony Holloway 
Cc: "Abhiram Kramadhati (akramadh)" , Matthew Loraditch 
, Charles Goldsmith , 
"cisco-voip@puck.nether.net" 
Subject: Re: [cisco-voip] UCCX 11.5(1)SU1 released

Atleast you had stock reports :)   I have done four UCCX upgrades 10.x to 
11.5(1)su1es01 and all four resulted in no stock reports after the upgrade. TAC 
root required to fix.

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuy06020

That being said, so far this version has been stable which is a good thing.



On Mon, Jun 19, 2017 at 11:51 AM, Anthony Holloway 
> wrote:
I did not open a TAC case, because Matthew was so kind as to have lead me down 
the path to fixing it myself.  I'll see if I can get the logs for you, but 
unicast email.

On a related topic to UCCX v11.5(1)SU1, I'm shocked this is still a problem, 
and that I have to make this change to Finesse. Every. Single. Time.
http://www.cisco.com/c/en/us/support/docs/customer-collaboration/unified-contact-center-express/118823-technote-uccx-00.html

On Sun, Jun 18, 2017 at 3:16 AM Abhiram Kramadhati (akramadh) 
> wrote:
Did you happen to open TAC cases for this? If yes, can you share the case 
number and if no can you share the install logs folder? Thanks.

From: Anthony Holloway 
>
Date: Sunday, 18 June 2017 at 12:25 PM
To: Matthew Loraditch 
>, 
"Abhiram Kramadhati (akramadh)" 
>, Charles Goldsmith 
>
Cc: "cisco-voip@puck.nether.net" 
>

Subject: Re: [cisco-voip] UCCX 11.5(1)SU1 released

Aand, one more.  Any Supervisor who was also assigned the Reporting Role, 
lost their Supervisor Group, so the Finesse Gadgets were showing the 
permissions issue still.  Fun times.



On Sat, Jun 17, 2017 at 7:34 PM Anthony Holloway 
> 
wrote:
I spoke too soon, the Historical Reports are also missing permissions.

Before:
Error! Filename not specified.
After:
Error! Filename not specified.

On Sat, Jun 17, 2017 at 7:27 PM Anthony Holloway 
> 
wrote:
So, I just hit this error too.

Upgrade was from 10.5(1) to 11.5(1)SU1ES01 and upon first login as Agent to 
Finesse I saw the error:


To fix it, I logged into CUIC and manually added the groups: Agents or 
Supervisors to the appropriate Live Data reports.  Refresh the browser and then 
it worked.

Example below:

Before Fixing It (You can see only Administrators could Exec/Read):
Error! Filename not specified.

After:
Error! Filename not specified.
On Mon, Apr 10, 2017 at 7:22 AM Matthew Loraditch 
> 
wrote:
And I had to reapply perms to all the reports… I don’t know whether I’m just 
special, but whatever update originally screwed up my CUIC perms (10.6 or 
something there was a bug…) has haunted me ever since. I don’t suppose there is 
a script someone in TAC could run to reapply default perms to everything in 
CUIC??

Matthew G. Loraditch – CCNP-Voice, CCNA-R, CCDA
Network Engineer
Direct Voice: 443.541.1518
Facebook | 
Twitter | 
LinkedIn 
| G+

From: cisco-voip 
[mailto:cisco-voip-boun...@puck.nether.net]
 On Behalf Of Matthew Loraditch
Sent: Monday, April 10, 2017 7:58 AM
To: Anthony Holloway 
>; 
Abhiram Kramadhati (akramadh) >; 
Charles Goldsmith >

Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] UCCX 11.5(1)SU1 released

So 

[cisco-voip] Jabber for Windows 11.8.x & Outlook Presence Issues

[Ruben Trujillo via cisco-voip]

Hello,

We noticed that after users upgraded to Jabber for Windows 11.8.3 the presence 
status in Outlook 2016 (Office 365) breaks.  We opened a icket with Cisco TAC 
and they informed us that this is due to the difference in the domains between 
email (company.com) and Jabber 
(jab.corp.company.com).  They suggested that we add 
a second SIP record in the "proxyAddress" field.  Unfortunately Office 365 only 
allows one SIP record and changing the existing one isn't an option.  Has 
anybody else noticed this and if so do you know what changed between 11.8 and 
previous versions?

Thanks,
Ruben

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] UCCX 11.5(1)SU1 released

[Matthew Loraditch]

My issues eventually led to being told to rebuild the system. So fair warning 
as further upgrades may become even more fun.

Matthew G. Loraditch – CCNP-Voice, CCNA-R, CCDA
Network Engineer
Direct Voice: 443.541.1518

Facebook | 
Twitter | 
LinkedIn 
| G+

From: Anthony Holloway [mailto:avholloway+cisco-v...@gmail.com]
Sent: Monday, June 19, 2017 11:51 AM
To: Abhiram Kramadhati (akramadh) ; Matthew Loraditch 
; Charles Goldsmith 
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] UCCX 11.5(1)SU1 released

I did not open a TAC case, because Matthew was so kind as to have lead me down 
the path to fixing it myself.  I'll see if I can get the logs for you, but 
unicast email.

On a related topic to UCCX v11.5(1)SU1, I'm shocked this is still a problem, 
and that I have to make this change to Finesse. Every. Single. Time.
http://www.cisco.com/c/en/us/support/docs/customer-collaboration/unified-contact-center-express/118823-technote-uccx-00.html

On Sun, Jun 18, 2017 at 3:16 AM Abhiram Kramadhati (akramadh) 
> wrote:
Did you happen to open TAC cases for this? If yes, can you share the case 
number and if no can you share the install logs folder? Thanks.

From: Anthony Holloway 
>
Date: Sunday, 18 June 2017 at 12:25 PM
To: Matthew Loraditch 
>, 
"Abhiram Kramadhati (akramadh)" 
>, Charles Goldsmith 
>
Cc: "cisco-voip@puck.nether.net" 
>

Subject: Re: [cisco-voip] UCCX 11.5(1)SU1 released

Aand, one more.  Any Supervisor who was also assigned the Reporting Role, 
lost their Supervisor Group, so the Finesse Gadgets were showing the 
permissions issue still.  Fun times.



On Sat, Jun 17, 2017 at 7:34 PM Anthony Holloway 
> 
wrote:
I spoke too soon, the Historical Reports are also missing permissions.

Before:
[mage.png]
After:
[mage.png]

On Sat, Jun 17, 2017 at 7:27 PM Anthony Holloway 
> 
wrote:
So, I just hit this error too.

Upgrade was from 10.5(1) to 11.5(1)SU1ES01 and upon first login as Agent to 
Finesse I saw the error:


To fix it, I logged into CUIC and manually added the groups: Agents or 
Supervisors to the appropriate Live Data reports.  Refresh the browser and then 
it worked.

Example below:

Before Fixing It (You can see only Administrators could Exec/Read):
[mage.png]

After:
[mage.png]
On Mon, Apr 10, 2017 at 7:22 AM Matthew Loraditch 
> 
wrote:
And I had to reapply perms to all the reports… I don’t know whether I’m just 
special, but whatever update originally screwed up my CUIC perms (10.6 or 
something there was a bug…) has haunted me ever since. I don’t suppose there is 
a script someone in TAC could run to reapply default perms to everything in 
CUIC??

Matthew G. Loraditch – CCNP-Voice, CCNA-R, CCDA
Network Engineer
Direct Voice: 443.541.1518
Facebook | 
Twitter | 
LinkedIn 
| G+

From: cisco-voip 
[mailto:cisco-voip-boun...@puck.nether.net]
 On Behalf Of Matthew Loraditch
Sent: Monday, April 10, 2017 7:58 AM
To: Anthony Holloway 
>; 
Abhiram Kramadhati (akramadh) >; 
Charles Goldsmith >

Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] UCCX 11.5(1)SU1 released

So we’ve been having tons of fun with live data and such so I updated over the 
weekend, now in supervisor Team and Queue data I’ve got this:

User does not have sufficient permissions for entity: 
C8E2DB0C114000A40A4E5E6B (minimum permission required: 
PERMISSION_READ_EXEC)


We are on Premium licensing… I’m digging around

Matthew G. Loraditch – CCNP-Voice, CCNA-R, CCDA
Network Engineer
Direct Voice: 443.541.1518
Facebook | 
Twitter | 

Re: [cisco-voip] UCCX script related questions

[Ben Amick]

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-boun...@puck.nether.net] On Behalf Of Terry 
Oakley
Sent: Monday, June 19, 2017 10:40 AM
To: 'naresh rathore' ; cisco-voip@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



From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
naresh rathore
Sent: June 19, 2017 1:48 AM
To: cisco-voip@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 

Re: [cisco-voip] UCCX script related questions

[Terry Oakley]

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



From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
naresh rathore
Sent: June 19, 2017 1:48 AM
To: cisco-voip@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

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] UCCX script related questions

[naresh rathore]

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

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip