If you have managed a contact center of any size, sooner or later, you will be asked to make a change on demand. A contact center supervisor feels the need to have a “team” meeting in the middle of the work day and needs the entire staff to be present. This means nobody will be logged in to take calls. This is the point they call you, the contact center administrator, and ask that you not only close the queue but record a new closed greeting. This happens so often that we determined to automate the process and put the power of opening and closing a queue in the hands of the Supervisor or Team leader. We created a Script, named CCAdmin, that is always running and waiting for a Supervisor to call it and make that famous request.
In the case of the CISCO UCCX, the script makes use of the Recording Step and the ability to read an XML document. Each operating script in the contact center has a “getstatus” subflow at the start of each script. This subflow checks an XML document, named for the queue, that has a single status variable. This is a simple boolean operation and it is either set to true or false. During normal operations it is set to false. The main queue script calls the subflow, finds the status as false and continues its normal routine of servicing clients. If however, the status is true, meaning that we have a special closing, the script branches to the closed section of the script and plays a special closed greeting, made by the Supervisor when they called into the CCAdmin script.
The CallCenterAdmin script has the matching setstatus subflow that is checked by the main script. When a Supervisor calls into the CallCenterAdmin script, they are prompted to select their queue by menu number. They are asked to Press 1 to open a Queue or 2 to close the queue and make a new recording. Then they are prompted for a PIN, which compares to a previously stored Integer to determine the Supervisors authority to make a queue closure. Assuming the PIN is correct, the CallCenterAdmin script, then prompts them to make their recording, thanks them and hangs up. The CallCenterAdmin script then setstatus to true and waits for the next request. All of the queue scripts in the call center have the getstatus subflow as part of their normal definition. As each script launches it tests for status and if closed plays the newly recored closed script and hangs up. When the Supervisor desires to open the queue again, they just place a call to the CCAdmin script and start over.
Though the concept is very straight forward there were a few kool tricks that needed to be developed. First of all, you need to define a naming convention that allows you to use a standard XML naming convention. So if we are checking the getstatus of the CustomerServiceStatus.xml we could use the same code we used to check the getstatus of the TechnicalSupportStatus.xml document. The setstatus of the CCAdmin script would also have to address this challenge. Likewise, making a recording and naming it so that you could use the same body of code or script was also an interesting brain teaser. CISCO UCCX enables the creation of Recordings wihtin a script, but ShoreTel does not. Likewise, CISCO UCCX can make use of XML documents as the database record, but ShoreTel would need a flat file or OBDC connector. I have been able to do the same script on a ShoreTel ECC, but I had to use a standard closed announcement as changing files in ShoreTel ECC on the fly, is not possible. You can point to a different previously recorded wav file, but you cant create on on the fly.
The application however, is very useful and we now deploy this as a standard for all Contact Centers we deploy. I will ultimately get the entire CCAdmin script into the lesson library along with the full prompt library as recorded by the first lady of all our prompts, Karen Brace of OnHoldAdvertising