Variable Screener messages affects service levels 1

[rwylie81]

Hi

We currently play a screener message when our call volums start to pick up, to let people know that they are going to be waiting a bit longer. This is controlled by a boolean variable. Not a problem.

However, when playing this message (say it lasts 20 seconds) and service level threshold is 30 seconds, we only have 10 seconds to answer call within service level. What I want is to have the service level for the application to kick in after the message has played.

I believe that the only way to do this is to use CDN1 -> Master (which has a section that plays screener message if variable set), routes call to CDN2, points to the 'queueing' application.

Any problmes with this?

 

[rfwhite]

That probably would work. Just remember that whenever you get fancy the reporting gets funky.

 

[rwylie81]

Thanks

IS there any issues surrounding going from Master back into Master. What is the best command to goto another CDN. Just route to?

 

[lretrievers]

The route command is intended to be used to route the call out of the Symposium. You either need to EXECUTE another script or EXECUTE a section of a script. Reporting can get complicated when you do these things.

 

[rwylie81]

Hi lretrievers , thanks for your reply.

The reason that I need to route the call back into symposium is so that I can get the service level timing correct after the screener message.

I am aware of the reporting implications (why aren't a concern) but want to make sure there are no system implications doing this.

 

[lretrievers]

You can cause other problems by routing back to a CDN that is in control of Symposium. A CDN is a Controlled DN which means that it holds the call until it can hand it off to something else, this means something "answered it". CDN to CDN transfers are not recommended. It is only with 2.02 of the Call Pilot software that Call Pilot could hand off calls to the Symposium cleanly, and it still has issues. If you do this I would monitor your Alarm Monitor very carefully, and do not be surprised with a PBX INI or a Symposium "crash".

I would recommend modifying scripts and use the EXECUTE script command before doing this.

 

[rwylie81]

Hi lretrievers . Thanks for your input.

We currently use the Execute script command.

CDN -> Mater (Which plays the Screener message if necessary then executes primary script). However the stats in the primary application still shows low service level becuase of the time the CDN was in the Master script receving the screener message.

 

[lretrievers]

Is there a way you could use the EXECUTE SCRIPT command instead of ROUTE CALL command so that it goes to another script? Perhaps you can modify an exisiting script and call it something else and that would actually give you information as to how often they are hitting the high volume message.

 

[rwylie81]

Hi

That's what we currently do. I am not interested in how many people here the high volume message, I just want the final script / application, to report on a 30second service level (after the message is played / or not played)

 

[lretrievers]

You can build another script and apply a different application threshhold to it which takes into account that there is a 20 second message. That's why I typically recommend. The timing would still be the same (because the caller actually waited that long) but it can change their stats for them so that they meet their service levels.

 

[rwylie81]

So let me get this right.

1 CDN points to master script. If master script plays screener message, then it executes Script1, with a 50 second application threshold. If master script doesn't play screener message then it executes Script2, with a 30 second application threshold.

Bob

 

[lretrievers]

Yes, you have it, that is what I would do and then you aren't routing calls in and out, it stays in control of the Symposium but just executes a different script with different threshhold settings.

 

[fonchick]

We have similar situations here -- we have instituted "zscripts" which we perform call treatment before routing the call to another CDN that then is pegged for reporting. For instance, if have a customer service script, we may need a zCustomer_Service script that checks hours of operation, checks if a boolean is set to true for a status message and plays the status message, or even plays a menu -- Then we route the call to another CDN that is pointed to the application that is being reported on. We were doing this in the master script, but we ran into issues with our master script size (the 50,000 character limit in 4.2) We only want our production applications to peg during hours and just for when the call queues. We have had absolutely no problems routing a call to another CDN from Symposium.