Martin Sloan CCIE Voice Candidate #211151677 speaks for the entire CCIE Candidate community (DrVoIP included) when he wrote the following letter:
I’m writing you this morning to express my great disappointment in regard to Cisco’s recent announcement to retire the CCIE Voice track with no reasonable upgrade path to the CCIE Collaboration. I know that you’re well informed as to all the arguments which are being made against this decision on Facebook, Twitter and other social media outlets, so I won’t go into any detail on why I think this is a bad decision. At this point, the facts are well laid out for everyone to see.
I’d like to ask you to please reconsider this decision and provide a reasonable upgrade path for the certified CCIE Voice candidates. I, myself, am not yet certified but I will make my first attempt on July 29th of this year. I don’t need to tell you how much time, money and effort I’ve put into preparing for this exam. It’s been a goal of mine since I first started on the CCNA. To completely retire a certification track that is still very relevant is incomprehensible.
At the very least, I want to request that Cisco provide it’s community with an intelligent argument to support it’s recent decision to retire the CCIE Voice without a reasonable upgrade path. We’ve heard very hallow responses citing new exam topics (that are already on v3) or that the description of the certification path wasn’t accurate with the technology. These answers are very much an insult to those that have been so loyal and sacrificed so much to achieve CCIE certifications. Please, ask your team to reach out to the community so we can come to an objective decision on this.
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
