cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6781
Views
0
Helpful
18
Replies

RESERVE time.....

staufferatmcws
Level 1
Level 1

I'm interested in knowing how other contact centers use the RESERVE time.  What is your "wrap time" set at?

Ours was set at 12 seconds when I came here.  When you add the ring time, customers were waiting an additional 12 to 21 seconds on top of the hold time before being assigned to the agent.  My goal was to reduce that time to reduce abandon calls in that window.  I had the wrap time reduced to 1 second, bringing the total reserve time to a max of 6 seconds.  The reaction from the CSR's has been interesting, and not positive.

4 Accepted Solutions

Accepted Solutions

Aaron Harrison
VIP Alumni
VIP Alumni

Hi Jim

Not sure quite what you are asking there... reserved time isn't configurable, it's the time taken for your agents to pick up the phone once it starts ringing. Many Contact Centers use auto-answer to reduce that; but generally if you go down that route you would have a sensible 'wrap' timer so your agents have time to breath/do admin between calls (and use headsets of course).

If that 12 seconds of wrap time is important to the agents (i.e. they are doing something productive during that time, that they now don't have time to do) then removing the wrap time is probably counter-productive.

If they just don't like it because it because they are being worked a little harder, then that's probably a management issue (i.e. a choice between increasing the agent count, or squeezing the existing number of agents further).

Given that your reserve and wrap time probably didn't amount to more than 20 seconds before your change, I would guess that most of your abandons are caused by the *other* queue time which likely amounts to more than 20 seconds.. if that's the case then staffing up (even just at peak times) may be the way forward.

Regards

Aaron

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

View solution in original post

Hi

Well - according to your diagram (at least how I read interpret it ) your 'reserve time' isn't affected by your wrap timer. Your 'reserve' time includes NetworkTime  (which is diagrammed as being after a call is routed to the agent, so is not wrap time as you suggest but the time taken for the system to set up the transfer to the agent) and RingTime at the agent phone. So the only way to reduce your 'ReserveTime' would be to reduce the actual RingTime (i.e. via AutoAnswer), as you probably can't have much notable effect on the 'NetworkTime'.

Since your 'wrap' time comes at the end of a call, the agent is not in a 'ready' state, so the call will simply queue, increasing your 'LocalQTime'.

So to reduce your queue time, you can reduce any of TalkTime, Wrapup, or Agent HoldTime (by streamlining whatever the agents are doing; maybe via CTI, maybe via training, maybe improving the systems the agents use etc etc.) or reduce the queue time directly by increasing the number of agents that can answer the call (or introducing some sort of self-service functionality if that is a possibility for you). It probably makes sense to identify where the bulk of the time is spent, wrap/reserve may be very small components overall.

What systems are you using? UCCX, UCCE etc.? Your terminology isn't quite what I'm used to..

Aaron

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

View solution in original post

It was explained to me that the call identifies a caller, then places the caller on HOLD for 12 seconds prior to connecting the call to an agent.  This is per a "delay wrap time step",   The "wrap time" shown above is 12 seconds, creating a 12 second delay to connecting the call to the agent. 

No, this should be the "wrap up timer" that is applied the agent workflow at the desktop to control their state.

When the current call is disconnected, the agent is placed into a "work" state. Like ACW in Avaya - they cannot get a call from the queues. There are two work states differentiated by the state that the agent is taken to automatically when the work state timer expires - thus we have "work ready" and "work not ready". Hardly anyone uses the latter.

There should be no timer in the script. It's been written badly.

Consider the following case. No callers in the queue, start of the day. All agents go ready - first caller comes in and has to wait 12 sec for an agent. Makes no sense.

Regards,

Geoff

View solution in original post

Hi

Well - if someone is referring to terms from the UCCE DB in reference to UCCX install and firing in random pauses to the script (which don't actually lighten the load on the CSRs, just delays it, so they are equally busy but 12 seconds later than they would be as all calls are presumably delayed equally) then it sounds like you definately need to review your scripts. Perhaps post them up so we can comment?

In UCCX you typically configure the 'work' timer as part of the CSQ configuration. You would set the 'wrapup time' parameter on the CSQ to the time you want to be in 'work', and usually you would set 'automatic work' to enabled so that it goes to that state automatically. The agent can then go to ready or not ready at any point during the work timer. If you leave auto work disabled, they have to select 'work' themselves.

Regards

Aaron

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

View solution in original post

18 Replies 18

Aaron Harrison
VIP Alumni
VIP Alumni

Hi Jim

Not sure quite what you are asking there... reserved time isn't configurable, it's the time taken for your agents to pick up the phone once it starts ringing. Many Contact Centers use auto-answer to reduce that; but generally if you go down that route you would have a sensible 'wrap' timer so your agents have time to breath/do admin between calls (and use headsets of course).

If that 12 seconds of wrap time is important to the agents (i.e. they are doing something productive during that time, that they now don't have time to do) then removing the wrap time is probably counter-productive.

If they just don't like it because it because they are being worked a little harder, then that's probably a management issue (i.e. a choice between increasing the agent count, or squeezing the existing number of agents further).

Given that your reserve and wrap time probably didn't amount to more than 20 seconds before your change, I would guess that most of your abandons are caused by the *other* queue time which likely amounts to more than 20 seconds.. if that's the case then staffing up (even just at peak times) may be the way forward.

Regards

Aaron

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

If they just don't like it because it because they are being worked a little harder, then that's probably a management issue (i.e. a choice between increasing the agent count, or squeezing the existing number of agents further).

Just one comment as an FYI. In Germany the labour laws are such that agents must have a short break (circa 5s) between incoming calls. In DE it is not a "management issue".

Regards,

Geoff

Ah yes... Germany does seem like a great place to work compared to other places; lots of protection from evil managers and companies :-)

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

Thank you for your response.  Our reserve time is made up of network (or wrap) time plus, ring time.  It is the wrap time that is configurable.  I've attached the flow diagram for clarity.

This change was one of several where we are focusing on reducing the total abandoned calls.  Not all calls require 15 to 21 seconds followup time and that is what our reserve time was doing for "every" call.

Change of routine is often difficult and I believe that is what this is.  The option to go into WORK state is available but, the CSR must change their routine to remember to do this before the customer hangs up.

In the end, this change may not be worth it.  When even your high performers have an issue, I would be a fool not to reconsider the impact.

Hi

Well - according to your diagram (at least how I read interpret it ) your 'reserve time' isn't affected by your wrap timer. Your 'reserve' time includes NetworkTime  (which is diagrammed as being after a call is routed to the agent, so is not wrap time as you suggest but the time taken for the system to set up the transfer to the agent) and RingTime at the agent phone. So the only way to reduce your 'ReserveTime' would be to reduce the actual RingTime (i.e. via AutoAnswer), as you probably can't have much notable effect on the 'NetworkTime'.

Since your 'wrap' time comes at the end of a call, the agent is not in a 'ready' state, so the call will simply queue, increasing your 'LocalQTime'.

So to reduce your queue time, you can reduce any of TalkTime, Wrapup, or Agent HoldTime (by streamlining whatever the agents are doing; maybe via CTI, maybe via training, maybe improving the systems the agents use etc etc.) or reduce the queue time directly by increasing the number of agents that can answer the call (or introducing some sort of self-service functionality if that is a possibility for you). It probably makes sense to identify where the bulk of the time is spent, wrap/reserve may be very small components overall.

What systems are you using? UCCX, UCCE etc.? Your terminology isn't quite what I'm used to..

Aaron

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

Not completely what I am used to either (UCCE specialist) although LocalQTime is a column in the Termination_Call_Detail record in ICM.

Duration of the call in seconds. This is the time that the switch is processing the call. The Duration field comprises several fields of the Termination_Call_Detail table: LocalQTime + RingTime + TalkTime + WorkTime + HoldTime + DelayTime + NetQTime

Regards,

Geoff

Perhaps I've made a mistake in assuming this flow matches our system.  We are using the UCCX system that I am totally new to.  This organization was left with little to no support after the system was installed.  Therefore, there isn't any documentation to pull from other than what is on the internet.

For these reasons, I turned to this forum to gain as much knowledge and understanding as I could get in a short time.  Below is the thread I saved where the flow came from.  UCCX was referred to.  And, so was the flow.   I made the connection they went together.

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Agent Desktop's agent state toggles between "ready" and "reserved

Hello and thanks for all of your past help.  I have a user whos'e Agent Desktop's agent state toggles between "ready" and "reserved when no calls are coming in to he IP Phone 7941 or 7961.  Can anyone help?

Thanks, Chet

Nathan Luk

nathanluk

59 posts since Jul 28, 2005

Currently Being Moderated

5. Feb 18, 2010 3:46 PM Re: Agent Desktop's agent state toggles between "ready" and "reservedin response to: abdulbaseer

Re: Agent Desktop's agent state toggles between "ready" and "reserved

Is the agent's phone actually ringing at all? If not I suspect the IP IVR ports are unable to call the agent. UCCX tries to send a call to the agent so it sends the reserve event to the agent and then tries to send the call to the agent but is failing so it cancels the event flicking the agent back into ready. Perhaps check to make sure that the ports have an appropriate calling search space to call the agent extension. Maybe configure a phone the same as the IVR port and check to see if you can call the agent extension?

Cheers,

Nathan

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Below is the "before" picture found in our script that led me to believe the Wrap Time was prior to the call being answered.

ClosedPromptPromptP[ICDclosed.wav]
ESDString"SanitaryCustSvcSD"
QueuePromptPromptP[ICDQueue.wav]
WaitTimeint0
WelcomePromptPromptP[ICDWelcome.wav]
WrapTimeint12
_TmpRsrc1188268451120Usernull
contactIDint0
resourceIDString""

It was explained to me that the call identifies a caller, then places the caller on HOLD for 12 seconds prior to connecting the call to an agent.  This is per a "delay wrap time step",   The "wrap time" shown above is 12 seconds, creating a 12 second delay to connecting the call to the agent.  This has been changed to one second to shorten the delay.

I've monitored the logs today and the RESERVE state has decreased from a range of 15 to 21 seconds, down to 3 to 14 seconds.

In the end, I may not find enough benefit to justify the impact to CSR's, even though the WORK state is their solution where needed.

It was explained to me that the call identifies a caller, then places the caller on HOLD for 12 seconds prior to connecting the call to an agent.  This is per a "delay wrap time step",   The "wrap time" shown above is 12 seconds, creating a 12 second delay to connecting the call to the agent. 

No, this should be the "wrap up timer" that is applied the agent workflow at the desktop to control their state.

When the current call is disconnected, the agent is placed into a "work" state. Like ACW in Avaya - they cannot get a call from the queues. There are two work states differentiated by the state that the agent is taken to automatically when the work state timer expires - thus we have "work ready" and "work not ready". Hardly anyone uses the latter.

There should be no timer in the script. It's been written badly.

Consider the following case. No callers in the queue, start of the day. All agents go ready - first caller comes in and has to wait 12 sec for an agent. Makes no sense.

Regards,

Geoff

Exactly!  When I started her a few months ago, I thought the same thing.  Why would we purposely wait an additional 12 seconds plus, the ring time, for customers that may have already been waiting?  I felt that extra 15 to 21 seconds (ring time) could be the time callers decide to hang up.  Makes no sense at all!

So, I've had the wrap time, that is located incorrectly on the script, changed from 12 seconds to 1 second, taking away all time from the CSR's.  They can, and have been going to WORK state to use as wrap up time.  However, they must remember to do this before the caller hangs up.  If not, the system puts them in READY.

I think it is time to bring in someone to consult with and reconfigure the script.

You could create a workflow through the Cisco Desktop Administrator that will automatically put the agent into "work ready" state on the drop event with a short (12s) timer.

Regards,

Geoff

Hi

Well - if someone is referring to terms from the UCCE DB in reference to UCCX install and firing in random pauses to the script (which don't actually lighten the load on the CSRs, just delays it, so they are equally busy but 12 seconds later than they would be as all calls are presumably delayed equally) then it sounds like you definately need to review your scripts. Perhaps post them up so we can comment?

In UCCX you typically configure the 'work' timer as part of the CSQ configuration. You would set the 'wrapup time' parameter on the CSQ to the time you want to be in 'work', and usually you would set 'automatic work' to enabled so that it goes to that state automatically. The agent can then go to ready or not ready at any point during the work timer. If you leave auto work disabled, they have to select 'work' themselves.

Regards

Aaron

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

In UCCX you typically configure the 'work' timer as part of the CSQ configuration. You would set the 'wrapup time' parameter on the CSQ to the time you want to be in 'work', and usually you would set 'automatic work' to enabled so that it goes to that state automatically. The agent can then go to ready or not ready at any point during the work timer. If you leave auto work disabled, they have to select 'work' themselves.

Thanks for that. My lack of Express experience is showing - I figured there was an easier way than having to make a CAD workflow. You seem to have the same abilities as UCCE, although done differently.

Regards,

Geoff

staufferatmcws
Level 1
Level 1

I agree, putting the script out here for your opinions will be helpful.  I appreciate the input so far!

I've attached a screen print of the spript that is in question.  I haven't been able to copy the entire scirpt.  It is the script before the change of the "delay wrap time".

Hi Jim

You could just post up the .aef file; there's rarely anything risky in there in security terms and it would allow us to comment fully.

What I can say is that I recall seeing that _TmpRsrcxxxxxxxxxx variable in an example script; basically what you are doing is grabbing a reference to the selected agent, putting in a completely pointless pause which will see your agents sat in 'reserved' status before the phone rings for a time equal to the 'wraptime' variable, and then resolving the earlier reference to an agent back to an actual user.

Now... whether something is done with that user later in the script is another matter; if you post the second part or the .aef we'll find out! I recall in the example script I saw with a variable of the same (and seemingly random) name that it wasn't used.. of course, it

Re: that wraptime, it's completely artificial and I can't see any reason at all for it to exist.

Regards

Aaron

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: