Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Out of hours calls on Application RTD 1

Status
Not open for further replies.

spoogle

Programmer
Dec 16, 2006
8
GB
i have a script which opens between 0900 and 1700. the threshold is 6 seconds less than the out of hours message. this means that calls before 0900 where the caller hangs up after the threshold time but before the end of the closed message (when the call would be disconnected) are counted as AAT and the service level (displayed on the application rtd) is hit.
the team leader uses the application rtd and is thinks they are doing worse than they are.
is there anything we can do about this (apart from telling the team leader to ignore the application rtd and look at the skillset rtd
 
It sounds like you are executing the open hours check in the primary script.

You can move this check to the master script. That way the disconnects are pegged against the master script and not against the primary script.
 
we do have the out of hours checks in the primary script and it's true that putting the checks in the master would solve the problem. however, we have a lot of primary scripts (about 40+) and to put the out of hours checks for each one in the master would be a hassle. is there any other way around it?
we do all of our out of hours check in the primary scripts (that's how it was when i inherited the system). does everybody else do it the master?
is the application RTD meant to be used as an indicator of performance (or does everybody else tell their call centre people to use the skillset RTD)?
thanks for the response Milesprower
 
the sort answer is no you can munipulate the scripts so that they act the way in which you want them to act i.e change the out of hours (ooh) timers or even change the wait timers or put the ooh message just before the closed message however this does not correct the issue only covers it.

As for putting the ooh in the master script this is very bad practise and advise the ooh may e completly different for each department within the callcentre.

Best practise is to have included only within the master script the following

1: emergency checker and section
2: call routing to primary script everything else is to contained within the primary script otherwise the master script can potentialy lock up chuck calls


Hope the above helps
 
Just as an add on thinking about it set the rtd's to reset at 09:00 thus giving you correct information and stats from 09:00 onwards

let me know your thoughts


sccsman
 
It is a little bit problem to tell call centre people to use skillset RTD if they are assesed by Apps Service Level.
I think to reset RTDs at 0900 seems well if you have the same oohs for all Depts.
You could also consider 2 posibilities for leaving your primary script after hours (calls are then answered either in secondary or another primary script and don`t affect SVL).
1. To send the call to the secondary script and to play message there followed by Disconnect.
2. In some scripts we use the solution which is not recommended. After hours we route calls
back to the Master via CDN. Advantage of this are additional CDN and Application
reports including CLIDs and CC people are happy to have numbers for call back.



 
thanks for the guidance on the masterscript sccsman. as for resetting the RTD, we have different opening times for different scripts. though i didn't know that was possible. how do you reset the displays?
i like the secondary script solution joynew68 (should have thought of that myself). i'll give it a go.

thanks for the help everybody.
 
Re. point above...

1. To send the call to the secondary script and to play message there followed by Disconnect.

Don't calls that are sent to secondary scripts still peg against the primary script (as you can't run a report against a secondary script)?

DD
 
Good point DD.
Currently I have no live system to test it but I am affraid that you are right - all delays in the secondary script will be still pegged against the primary application.

j.
 
I tried the secondary script method and (as DD and joynew68 have pointed out) it still pegs the calls against the primary script. I've assigned a spare CDN to the OOH script and put it into the masterscript. This has changed the OOH script to primary. I thought that might do the job but the calls are still pegged against the first primary.
I'll have to go with joynew68's other suggestion (routing calls back to the master). I've tested it and it works.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top