Can you create a “killer” Contact Center Script?

Most Scripting engineers working with Contact Center deployments built on CISCO UCCX, ShoreTel ECC, or Avaya have amassed a collection of script subroutines.  These subroutines are used over an over, from script to script to avoid having to recreate them for each new deployment.   Most every script needs to check a holiday schedule, check for Service Level parameters and update language options.  Why not have your new script call on one of your existing library scripts, a technique used by software engineers since the first line of assembly code was written.

We have always been preoccupied with the concept of a “killer script”.  A single, reusable script that can reconfigure itself to meet the specific requirements of the call flow required to satisfy a particular contact center application.   This concept continues to preoccupy our thinking. Saving deployment resources also reduces deployment costs, implementation, test and turn up time.  It also eases long term maintenance and documentation efforts.

DrVoIP has emerged a “root” script that we use as the base line of any new deployment.   It contains a number of subflows, prerecorded generic prompts and call handling options that enable us to move a new call center to operational status quickly and with confidence that our code meets requirements, both known and likely to emerge as management experience is gained operating the new setup.

Using a “QueueOptions” XML file we are able to read in options that reconfigure the script each time it is launched.   Using DNIS as the variable that indexes the XML filewe can choose custom prompts, determine if a Menu, or IVR needs to be launched or if the caller needs to be routed directly to the agent pool.  We can also retrieve the name of the Agent Pool or CSQ, determine what options should be offered callers in queue and provide customize queue messages and even push out custom screen messages to the agent desktop.

The core script is the same for applications, the elements of which, are customized based on the called number.  We use a value that determines DIRECT, MENU, IVR, or UTILITY which will call on the necessary subflow to provide the custom call flow.   One CSQ might hear a different Menu of self navigation options then another caller might hear based on the number they dialed.

We have even emerged a range of custom numbers that minimize the potential for digit conflict.  We set the triggers in our applications, or the numbers that launch the script, to 3009998000-8999 for example.  This ten digit number looks like a typical +1 area code and number, but it can not be dialed.   As such it is an ideal way to standardize on a script that can be reused without having to worry about changing triggers.

The script can call subflows for options that might not be needed for each caller, but can be initiated if required.  For example, holiday checks, call back options, special emergency call center closings.   Audio Prompts are numbered to allow prompts to be specified but drawn from sub directories that are identified by the values stored in the XML file, indexed by the number called.  Using numbers instead of names also allows us to create a script that can allow a supervisor to re-record a specific prompt at will.

The UCCX version of this script, the generic audio prompt library and the QueueOptions.XML file is available in the subscription video library on the DrVoIP site next to nothing.  We have tested and debugged version 1 of this script using Version 8.5 Enhanced license, so I can be easily upgraded.   We will update the script with options for schedules, menus, prompt re-recording and interface it to some of our previously released modules.

Save the software!  We are now working on a similar concept for ShoreTel ECC.  The video walks you through the design concept and illustrates key elements of the core script.  Keep the cards and letters coming! – DrVoIP

Run ShoreTel on Vmware Player or Oracle VirtualBox!

With the release of ShoreTel Version 4.2 the company introduced the concept of virtual appliances. These software objects, had the potential of replacing the Orange ShorGear hardward boxes that typically characterize a ShoreTel deployment. The wisdom of trading the power of dedicated hardware based digital signal processing chips for the variable power of a shared computing resource aside, there are any number of advantages to using “virtual machines”. Currently ShoreTel supports Vmware ESXi and Hyper-V, so we thought we would push the envelop and try alternatives, for example Oricales Virtualbox and Vmware’s Fusion and Vmware player and see what results we could achieve. Just for kicks we thought we would see if we could inport and OVA file into Amazon Web Services and run a ShoreTel switch instance in the cloud!

The ShoreTel OVA and ISO files are distributed with Version 14.2 and you can link to them in several ways. They are in the intetput, ftproot folder on the ShoreTel HQ server. You will find two folders TSU and TSV, each with an OVA file and an ISO image. The TSU folder contains the objects necessary to create the Conference Appliance and the TSV folder contains the Phone and Trunk Switch objects. Think of the OVA file as a configuration profile that draws the outline of your virtual machine and defines the basic hardware configuration. The ISO image, contains the operating system. In the case of the ShoreTel ISO, it is in fact a Windriver Linux distribution, which has its roots (excuse the Linux pun) in the

Clearly, ShoreTel is cutting the cost of goods, by reducing the need to produce Voice Gateways. It does not look to us however, that they are passing any of that reduction off to end users however. The cost of implementing a virtual ShoreTel Gateway is not much different than the cost of actually buying the hardware solution. The motivation for using the Virtual machines must be based on something other than acquisition cost. For we engineers however, it is fun to play with. You can spin up a machine in short order and use if for 45 days before you have to pay for the licenses. In the case of the conference appliance, there does not appear to be any cost other than the hardware used to run your Virtual Machine.

There appears to be three options for virtualization: the conference server; a phone switch and a trunk switch. The conference server lets you create an environment for web based conferencing and desktop sharing. The phone switch is a direct replacement for the ShoreGear family of users switches. Likewise the Trunk Switch, enables you to create SIP Trunks. If you have no hardware to connect, there is no reason that you can not put your users on a virtual switch. In fact if you have no copper connected to your VoIP deployment in the form of analog phones, telephone company analog lines or digital lines, your entire ShoreTel soltuion can be a figment of your imagination, living only in a virtual world, HQ server included!

Ingate apparently has made a Session Border Controller that is virtualized and may be integrated with the ShoreTel Trunk Switch, but we have yet been able to get a test device in our lab. Having a Virtual Switch configured and available as a “fail-over” solution or secondary switch in a ShoreTel deployment makes a lot of sense to us. You can configure the switch, put it live in your deployment and you only pay for it if you actually fail users over to it and you have 45 days to think about it! We have been able to successfully deploy ShoreTel in an Amazon Cloud, completely in software, using SIP trunks and remote phone registrations over VPN. There are lots of powerful options for deploying a virtualized ShoreTel, limited only by your imagination!

We attempted to deploy ShoreTel on an Oracle VirtualBox but keep running into an issue with the network adapter settings. The ESXi version of Vmware allows you to create a soft ethernet switch and route it to the rest of yoru network. The VirtualBox achieves the same flexibility allows you to NAT, Bridge or establish a host only NIC card. As the Virtualized ShoreTel switch needs to communicate with the rest of your deployment, you need configure the NIC card to Bridge or NAT. Both Fusion on a MAC and VMware Player on PC’s resulted in working ShoreTel switches without to much drama. We were able to bring up VMware Player on the ShoreTel HQ server and build out a Conference Server replacement for the SA-100 Hardware solution with little issue.

Candidly, these are not supported ShoreTel configurations, but we are just engineers playing with all the kool stuff! Remember that if you clone your virtual machines you will need to change the NetBios names and IP addresses before they can be useable in the same deployment. The embedded video is an overview of how to configure both the Free Oracle Virtual Box and the Vmware Fusion for Mac and Vmware Player for Windows to run ShoreTel. Keep the cards and letters coming and remember to support the GNU project!