Not Ready Codes
Not to sure if I should put this here or the after hours section.
I have an existing system running with ACD. I have been sort of tasked at looking at introducing the Not Ready Codes (so somebody else can keep track of staffing levels).
Can anybody let me know the problems we will be facing, technical or personnel based.
Thanks.
Question asked by Paul
Not Ready Codes
Paul,
Having not played with your ACD yet I may be barking up the wrong tree here but..
AFAIK Call (Event) Codes relate to the actual outcome of a call eg:
101: Client not interested
102: Already purchased
103: Unable to reach decision maker
104: Answer Machine
105: Unable to talk as Granny’s stuck in the Rottweiler
and so on.
I’ve never come across them being used for Not Ready Times
before as they are normally entered as the call finishes and
before the turret ‘Wraps’ itself waiting to be put into ready.
I just use Total Wrap time (sec) / Calls taken added
to the Average talk time to give my average handle time.
It may be that you are on about something slightly different that
we call IOT (indirect Operational Time) this is working time that agents are
unavailable to take calls. Examples are Team Meetings, Short notice leave, Training
sessions, Staff Briefings, 1:1’s, Non-Phone processing and Sickness.
This data I collect by team by week and use a weighted average for an allowance
to add on when I re-roster.
If I’m heading in the wrong direction please let me know.
HTH
DaveA
With thanks to Dave
Not Ready
Thanks Dave
As you have probably guessed I am looking at using the codes basically backwards. Rather than describing what the last call was for it is more to suggest why they have decided not to take calls for a period of time. I am not aloud to call the department a call centre it is Customer Services, and therefore as it is not a call centre some people don’t understand why they need to use their phones…..
In fact on re-reading your post our use of the NRC is very akin to you IOT. This sounds a much nicer term and as long as it not copyright 🙂 I may suggest it here.
Thanks Dave.
With thanks to Paul
Not Ready Codes
Paul
The ACD system should support a number of not ready codes to describe why your CSR’s aren’t available to answer calls. From a resource planning point of view these can then be used, as Dave suggests, to uplift the base staffing requirement to take into account non-phone states that the agents will be in whilst at work.
As a start I’d suggest that you create codes for
Wrap (after call work directly relating to the call just taken)
Breaks
Meetings
Training
Admin / other non-phone work
Plus a general “Not Ready” code to cover things like going to the toilet, getting a drink etc.
I’d suggest though that you introduce these a couple at a time to get the CSR’s used to the process.
You should then be able to compare reports from the ACD to your resource schedule to see whether the time you allocated for each activity is actually what the CSR’s delivered (Adherence!).
Hope this helps
Eamon
With thanks to Eamon
Wrap Up
Hi Paul,
We are using the Not Ready Codes in our ACD system. It’s a good way to report how the agents use their time while not taking calls. However you are dependent on the agents using the right codes and not just the general not ready code (for “other” non-phone work).
In our situation it often seems like that’s the case. We just threat that information as ‘nice-to-know’ instead of reporting these stats.
Another question related to this; We also have a “wrap-up” not ready code. But as I described above, often the agents seem to be using the wrong NR code.
This is my first time with this ACD system. Does anyone know if it is at all possible to have the phone automatically go to Wrap up state (or a wrap up NRcode for that matter) after the call has been ended?
I want to be able to report wrap up times but have to be sure these times are accurate.
So, what I want is: Call-> call ends -> phone goes to ‘wrap-up state’ Automatically -> Agent does his/her wrap-up work -> Agent puts phone on Available for next call.
With thanks to Thomas
Its Behind You
Beware making your not ready codes too specific, all to often agents regard them as big brother stats with analysts measuring time ever more minutely to clap down ever harder on even the tiniest millisecond of nose scratching time.
Sure its useful to know how you are losing productive time in not ready or too much wrap and if that’s generated by cumbersome back end non user friendly systems then it needs to be addressed. Normally though your TL’s and trainers should be able to accurately report on training and one2one sessions etc. Anything else isn’t profitable time usage and it doesn’t really matter what it is or to some extent how its allocated what matters far more is that you educate agents to minimise it without them feeling spied upon.
People hate being covertly analysed, statistics don’t mind it so much.
With thanks to Closed
That Old Chestnut!
Getting correct info out of Event codes
is always a nightmare. However the other problem you have…
We’re about to start an ACD upgrade here in the next
couple of months however I’ve never found a switch where IT’S NOT
possible to Auto Wrap the calls.
We’re heading a bit out of my area but I’ll have a word with our
implementation team and see if they know how.
HTH
DaveA
With thanks to Dave
Auto Wrap
With ACD Wrap is a subset of Not Ready, the agent has the Break time at the end of the call to enter Wrap or wait until back in Available to enter Not Ready.
The purpose being that Wrap is linked to the previous call in the skillset table to track the true handling time, whereas Not Ready is for other activities not linked to the previous call and hence not part of the handling time.
Auto Wrap would mean an agent would have to enter Wrap, Select Not Ready again to go into available and the Not Ready again to enter the Not Ready state.
One problem with ACD is that an agent can enter into Wrap to commence follow up actions, but if that follow up involves a DN call the moment DN is selected the Wrap data is wiped and becomes Not Ready time only. Total pain in the *ss when you have spent months training agents one way to ensure metrics are recorded for a full handling time by skillset and then find the d*mn process fails as soon as a DN call is made.
With thanks to Julian
Happy People
From a people point of view, how this is briefed out to staff will make or break.
I used to co-ordinate operations at one location of a multi-site set up.
We went to simultaneously roll out such codes (break, lunch, ‘bio’ (ie loo), team meeting, training, 1-1 and a couple of others I can’t remember now) at two sites. At one (not mine!) there were near riots, threats of industrial action, great staff unhappiness, loss of productivity and general discontent. At mine it was a five-minute wonder and everyone just got on with it.
The difference was how it was briefed to the staff. At the other site, the supervisors were pretty much just given a list of codes without explanation and told to get on with it, so it was put to staff in a similar fashion. At mine, I held a series of briefings with supervisors and a rep from each team (and offered to attend any team meetings if required to face interrogation) to explain WHY we were doing this and how it would benefit them (ie better planning of the things that they liked, like breaks and meetings and training). I also tackled head on the issue of intrusiveness and said that the only reason we were asking them to put in a code to go to the loo was so the system knew to discount it. I produced everybody little stickers with the codes on to put on the phones and put silly messages as reminders across the wall-boards.
There was high compliance with code entry at my site too, which meant that the extra time I invested was saved in the long term.
Hope this helps!
With thanks to Zoe
Politic
I agree with Zoe and like her have first hand experience of it being implemented with buy in and without – the former being much more preferable and resulting in far less abuse.
In the words of Blair “You gotta spin it”
With thanks to Closed
Wrap Up Codes In ACD
I agree with most of what has been said, using codes can be classed as demotivating, and the codes can be too rigid.
I am currently using ACD, and have upgraded. Wrap us codes have been a complete waste of time with this system for the following reasons:
1. I introduced wrap up codes so that Team Leaders could monitor real time stats, and view the status of the agent. The major problem with this is that the real time system does not include the status of the advisor eg. Lunch, Break etc. The only viewable status is active/not ready/logged out. this defeats the object of the exercise really.
2. Reports, ACD has lots of reports and most of them you really cannot use, or if you do you will want to run 4 reports instead of 1. For what ever reason trying to obtain a report which includes the time people logged in/out, lunch times started and finished etc involves linking multiple databases in crystal developer. After completing this task, the results I obtained were not really what I wanted.
What I have resorted to is a web based system on the intranet which is acceptable by the advisors and they log in and out with appropriate codes on this web format, and then log out of the phones. The intranet is then linked to SQL which means I can report alot easier.
With thanks to Mark
DN Time In ACD
Hi
I realise this is a late response to this thread!
Often we make DN calls to customers/stores when we are on the incoming call, it appears that running a Talk time report includes this DN time, and the DN time report will also include it as well but not differentiate if the DN call was made in Not ready or on an inbound call.
Also did anyone find a way to auto code all not ready as PCP?
Thanks
Paul
With thanks to Paul
DN Time In ACD
You may be interested in ACD as it now puts DN Out time into the Skillset Stat tables.
Deducting this from the Performance Stat DN field should give you the difference you are looking for. The method used is to peg the next Dn call made against the previous skillset answered, also it differentiates internal (on switch) and external dialling. Unfortunately I have not yet been able to test this to fully understand the implications of “previous skillset”, eg the timelag before it stops doing this.
The Wrap/Not Ready issue continues to rage on, but perhaps the above change will fix one bug – the one that cancels out Wrap when the agent initiates a DN call during the wrap period. That really p**d me off when calculating handling times.
With thanks to Julian
Author: Jonty Pearce
