Can I text your Enterprise Contact Center?

Posted on February 6, 2015 by DrVoIP

Phone only ‘call centers’ have been rapidly replaced with ‘contact centers’ that can also handle email and chat communications. Customers want more options for interacting with companies they buy products and services from. Chat requires the customer to be at a computer and though email may be sent from a mobile phone, generally the sender is at a desktop. In a wireless world in which every man, woman and child seems to wonder around with a ‘text’ or sms enabled device on their person, does it not make sense that they would want to text your call center?

Most call centers seem to be comfortable adding more and more incoming telephone lines, but never seem to add more agents? We now queue up more clients to the same number of agents and expect that our customer satisfaction scores will increase with each new telephone line we add. Chat and email increase the options that an agent can use to communicate with a customer, but only text offers location independent immediacy and the highest level of accuracy in CRM integrations.

A text will be read, on the average, within 10 seconds of its arrival. It has a significantly higher read rate than email. It is considered spam free, as you must opt in from you own mobile phone to receive future text messages. As most folks under 30 do not even have a land line, using the CID of a SMS text will yield a much higher accuracy rate when doing screen pops from CRM integrations. Self Service options for SMS are enormous and scheduling an agent call back could not be any easier!

What would you rather do: call into a contact center, listen to the obligatory menu of options, self navigate to the customer service group and then hear the first queue message: “the next available agent will be with you momentarily”; or send a SMS text message directly to the contact center group, by passing the automated attendant and if you do not receive an immediate call back, receiving a confirmation text that an agent will call you at your mobile number in four minutes?

We have created a website to enable you to immediately setup a text based marketing campaign! You can create an account at our TEXT PORTAL and select a phone number for your campaign and be in the digital marketing world in minutes. We give you free SMS credits when you activate your account! Interested in extending this capability to your Contact Center? We can implement text functionality to your ShoreTel Contact Center or CISCO UCCX in a matter of hours!

Contact DrVoIP@DrVoIP.com or send the word CALLME to 603-426-3253 for sample application! If you would like to test T2E (Text to Email) text your email address to the same number and we will set you up. – DrVoIP

Looking for a UCCX Wall Board? – VSR2 has the vision!

Posted on September 28, 2014 by DrVoIP

If you have ever considered adding a Wallboard to your CISCO UCCX based Contact Center deployment, you know that the selections are slim. There is a wealth of unsupported “freeware” solutions on the net, generally the failed result of someone trying to “roll there own” wallboard. Clearly, you always have that option if you have the time, talent and ongoing commitment to support Cisco’s follow on versions and upgrades. To assure ongoing compatibility with CISCO, you need a dedicated development team! Finding a vendor supported wallboard that does not cost as much as the UCCX itself, however, has been very difficult until now. We recently had the opportunity to work with VSR2, a UK based CISCO partner who has been building software based solutions since 2007. The VSR2 UCCX Wallboard product offering is both an astonishing accomplishment and a must have product for any serious call center deployment. Not only is the product exceptional, but the entire team behind the product is a real joy to work with!

The VSR2 installation is very simple, but it is generally done by a factory engineer over a remote desktop or TeamvViewer type remote connection. The VSR2 solution runs on a Windows Server under IIS and interconnects with the UCCX over an Informix database connector. Simply provide the usual UCCX database credentials and if there is network connectivity between your Windows Server and your UCCX server the install will be completed in less than 30 minutes, most of which is spent waiting for Microsoft! We worked with an excellent engineer, Victor Spirin, who was very helpful in answering questions and also provided an initial over view of the systems capabilities.

We successfully tested the VSR2 on both UCCX Version 8.5 and Version 9 with no problems, or show stoppers to report. The Wallboard is easy to customize and there is a great deal of flexibility in every aspect of the configuration. Your can select your columns, content, color and triggers. You can create multiple CSQ wallboards, or Agent based wallboards. In fact you can create a library of wallboards and you can send supervisors links to previously created wallboards. VSR2 has also developed other tools that are effective for Call Centers including a call recording capability, but it is the VSR2 wallboard that brings this company to the forefront! They offer a 30 free trial and if installed, it would be hard for us to predict that it would ever be removed! Take a look!

Hacking ShoreTel with Wireshark or Trouble Shooting One way Audio.

Posted on August 19, 2014January 14, 2024 by DrVoIP

My First Hack?

When I was a little kid, back when there was black and white TV sets and 33 RPM records, I was always amazed at the work of the telephone company repair man! At that time there was only one Phone Company. When they sent a repair man out your house he arrived in a drab olive trunk like those used by the Army. The telephone repair man had a belt of tools including a very Kool line mans “butt set” or handset and some really super hand held drills and other stuff.

I remember watching as he installed our new “touch tone” wall phone! Then I watched as he took the “butt set” from his tool belt and like all those spy movies, he clipped it across the copper wires, which I later learned were Tip and Ring, to test the circuit! I did not even have to ask, I could hear it. When he clipped across the wires he could hear the conversations that were being held on that circuit. How freaking Kool is that!

Now with IP or VoIP telephony, the butt set has gone away, but listening in on phone calls is still possible. Forget the NSA, is one of your employees copying and recording your conversations to a USB drive and posting it on Facebook? The fact of the matter it is easier than using that old “butt set” which required a physical presence and an ability to touch the circuit. With VoIP, you can “remote “in from anywhere on the planet, do a remote packet capture and leave little or no trace that you were even there. In fact, using some deep net technology like Tor, or stacking multiple virtual machines in an Amazon cloud, not even the NSA could trace your route!

Network engineers long ago figured out they could not see the packets that run around the local area network, let alone those that go off into the Internet. Tools were needed to capture the packets, slow them down and sequence them through a protocol analysis. One of the early on tools to do this, now named Wireshark, is the minimum daily adult requirement for network trouble shooting and must definitely for VoIP problem analysis. With this software tool, a network engineer can capture all the traffic moving over the wired or wireless network that interconnects your office to the World Wide Web, and save it for future analysis. The TCP/IP protocol, though a mystery to the uninitiated, is like a microscope to a network engineer or serious hacker.

It continues to amaze me that technologically I can position myself as a “man in the middle” and basically watch as you type your user name and password into your favorite website. Bored teenagers or “script kiddy’s” now do this for light entertainment. Again, forget the NSA, your teenager has more ability to track your internet activity and probably more reason to do so. Now apply this concept to your VoIP network, and you have much the same situation. It is very possible to gather up the packets on your local network, or in route to your SIP provider and reassemble them into complete phone calls.

Next to QOS issues, “one way” audio issues are among the most common of VoIP network issues. When trouble shooting these kinds of issues on ShoreTel deployments, we typically telnet into each phone in the conversation and ping our way from the phone, to the default gateway and back to the other end. Invariable we find a configuration error in a default gateway somewhere on the network. QOS issues are best solved with a protocol analysis and verification of call control signals.

This is where Wireshark comes in.

Version 14 of ShoreTel simplifies the use of Wireshark. As a Network Engineer you are aware that if you install Wireshark on the ShoreTel HQ server, you are only going to see unicast packets sent to the Server or multicast broadcasts set to all devices on the network. Wireshark will not see unicast packets sent to the other devices on the network unless you setup remote monitoring or port mirroring. With Version 14 of ShoreTel, you can setup remote monitoring from the HQ server and copy packets for analysis and assembly. Voice or RTP media between ShoreTel phones and ShoreTel Switches is encrypted while on the network. Media traffic between devices in not encrypted and can be captured and played back. MGCP, unlike SIP, treats RTP as UDP and you will need to modify Wireshark preferences to capture it as playable voice.

The accompanying video walks you through the process of capturing VoIP traffic, looking at both MGCP and SIP call control and how to assemble voice and media streams for playback.

Can you create a “killer” Contact Center Script?

Posted on July 17, 2014 by DrVoIP

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

Holiday Check script is a great learning tool!

Posted on April 24, 2014 by DrVoIP

Most VoIP Engineers are not necessarily Software Engineers, so bringing up a Contact Center and scripting it are usually done by two different types of engineers. Scripting engineers tend to have backgrounds in software development with formal education in programming structure and practices. A solid experience in Java, PHP, Perl, SQL and other languages is very different that having a background in IP networking, telecommunications, QOS and MPLS! That is not to say their are not Engineers that can do it all, but you can either be a mile wide and an inch deep or an inch wide and a mile deep! You can’t be an expert in everything!

Scripting a Contact Center using the CISCO UCCX editor and related tools is an area of specialization. Most engineers carry around a basic set of “start up” scripts to get a new UCCX off the ground, but most clients have contact center requirements that require CRM, Website and advance database integration that requires some additional depth of expertise in the area of software development. Altering call flow based on external data elements is an essential part of any contact center today. The need to retrieve data from sources outside of the script, or to update sources once the script completes has become the minimum daily adult requirement for contact center scripting!

There is a HolidayCheck script that has been kicking around the CISCO UCCX landscape forever. We first saw it in the Windows based UCCX before Version 8+. It is actually a great script as it demonstrates a number of Java elements that are outside the normal cut and paste scripting ability of many newbies. You will need to understand XML, Xpath, String Manipulation, Date Contractors and some other advanced data handling options that this script uses to modify call flow based on the day being a holiday or not. For this reason, it makes for an excellent learning tool if you want to get in their and dig into the details.

The Script uses a simple XML data file containing a list of dates that are declared to be Holidays. Generally, the script is a sub flow, called on by a parent script to determine if we need to close for the day. The script first finds out what is the date today, then goes through the XML date list comparing each entry with todays date to make a holiday determination. If it gets through the entire date list without a match, the returned value is false. If it finds a match the returned value is true! Very simple, however the process uses about every programming trick in the book and for that reason it is fun to learn how the script works. It is highly efficient using less than 15 lines of code to do its magic!

We have also found the script to be useful for deriving other uses built on the same constructors. For example, finding out if we should be open or closed based on the time of day. The Time of Day Java bean in the UCCX library is great if you want to open and close once on a particular day. If you want to open at 7AM, close at 11 for lunch, then open again at 1PM and close at 5, it is a bit more difficult. Creating an XML document with the schedule for a particular CSQ, is a lot more useful! In fact we can economize on script reuse by pulling CSQ details from a QueueOptions.xml file and dramatically alter the details of a specific CSQ while reusing the same core script! XML is the way to fly, especially if you can use HTML and web technology to feed your script user specific call flow details like “call me back at this number” please.

Do to this kind of scripting you need to have a handle on string manipulation, XML, data type conversions and Xpath. For this reason the HolidayCheck script is a great learning tool. The video walks throughout the details of this script and provides, we hope, some useful instruction. We don’t know who wrote the original script, but it has been plagiarized by us all and it is remarkable when it is studied by those who want to learn its secrets!

Members can download the script from the DrVoIP.com site!

Top 5 Trends Transforming your Contact Center!

Posted on April 9, 2014 by DrVoIP

The Contact Center is being transformed at a rate of change that is beyond the ability of current management strategies to identify and react. Most contact centers are still using 1990 thinking in a 2020 world! The adoption rate of Smartphones, customer satisfaction scores through social media, wide availability of video options, and the mobility of customer demographics are terrorizing your call center and what are you doing about it? Still routing phone calls based on Area Code? Queueing Callers on more incoming telephone lines, while employing less customer service representatives? Unless you are Google or the IRS, neither of which cares about customer service, you are about to become extinct! Here are the top five Contact Center Killers of traditional business models!

(1) Scheduled Call Back – The traditional strategy for customer retention has been to increase the size of the “catchers mitt” by adding more incoming telephone lines. Nobody ever says lets increase the number of agents answering incoming calls, but they are always quick to add more incoming telephone lines! All this does is increase customer frustration, pressure agents to short change the current customer interaction and drive abandoned calls through the statistical roof! Do not even consider this option until you have explored all the other options listed below!

(2) Mobile Phones – Without exception, unless your client demographic is that of the Jitterbug generation, your clients are mobile phone users! This means they have advanced smartphone functionality, SMS or Text capability and they are web savvy! Tap the functionality of these devices to increase customer satisfaction while reducing over all costs. Text messages can be used to initiate the Call Back function in your contact center! Smart Aps can be created to help clients “self navigate” through your call tree, with the the push of a single button! Get Smart Phone integration into your contact center yesterday!

(3) Video Support – High “touch” now means Video! The traditional talk path is narrow, strangles information and is inappropriate for todays high speed, information rich customer contact strategies. Video offers a deeper and richer personal experience. When it comes to “show me”, “teach me” and “help me” scenarios, one call completion statistics escalate when video is part of the contact center arsenal of customer satisfaction tools. Get your Frequently Asked Questions into video format, or risk being ignored by a generation that might be able to read, but find YouTube a faster route to problem resolution.

(4) Social Media – Twitter can do more to damage your reputation than a bad restaurant review on Yelp! What social media monitoring tools are in your contact center arsenal? What website integration options have you implemented? Can your Customer Service Representatives open a real time video conversation with someone who has hit your website, or just told all their FB friends what the current hold time is in your Contact Center?

(5) Home base agents – did you read (1) above? The availability of hight speed network connectivity, now makes it possible to tap a labor pool that has nothing to do with driving distance to the office! Quality, trained and experienced Customer Service representatives are out there, living where they want to live and are available to the Call Center that has put distributed workforce connectivity solutions in place. Down the hall, or across the country, you can provide the exact same supervision, monitoring, and training for a remote customer service representative that you provide for that boiler room Contact Center that you heat, air condition, power and remains your biggest disaster recovery and business continuity challenge!

At DrVoIP we create software integrations that enable solutions for these Contact Center terrorists. No need to throw out your current ShoreTel ECC or CISCO UCCX, we can wrap these solutions around your existing facilities with rapid deployment prototype options that have high impact and low exploration costs. Click or Call!

UCCX Cheat Sheet – Agent Log-in in using Extension Mobility!

Posted on March 5, 2014 by DrVoIP

There is a two step process for logging into the systems if you are a mobile worker. The first step is to log into a Telephone and make the phone your Extension number. The Second Step is to log into the CISCO Agent Desktop (i.e. CAD) and make yourself ³Ready² to receive calls from the Contact Center.

Step One: – GoTo the phone you are logging into and press the button labeled ³services². This will bring up a list of Services that your phone supports. You should one or more services. Select the Service entitled ³Extension Mobility² by highlighting it with up/down scroll button on phone or entering the menu number.

Step Two: You will be prompted to enter your User Name and PIN. The User Name is your Active Directory (i.e. AD) login name, usually in the form of First Letter of your First Name followed by your Last Name. For Example, pbuswell. You will have to use the Touch Tone Pad on the phone to enter your name, and it is a bit cumbersome, but you will figure it out. The PIN number, unless you have changed it, will be the default of 12345678

The Phone should wink and blink¹ and reset itself. When it comes back alive, you should see your Extension number in the Display of the Phone. This means you have successfully logged into the phone on this desk! Please remember to reverse the process and LOG OUT when you are done.

Step Three: Log into the CAD, by bringing that software up on your associated computer. This will be a Short Cut on your desktop, or you will find it with your mouse under the Start, All Programs, CISCO, Desktop, Agent. You will then be presented with a screen that prompts for your User Name, Extension and Password. Enter your AD user name as used in the above step. The Extension is to match the Extension on your phone, and the Password is your AD password.

This should log you into the Contact Center and bring up your Agent Tool bar similar to the one below, though your buttons may be smaller. To indicate that you are READY to receive calls, you will need to push the READY icon (mouse over ICON) to see what they do! When you do not want to receive calls, you will push the NOT READY icon. At the top of the tool bar you will note your current Status!

UCCX Scripting – Working with XML documents

Posted on October 18, 2013 by DrVoIP

When writing call control scripts for Contact Centers (ShoreTel ECC, CISCO UCCX ) do you really have to start over each time? Are there really that many differences between contact center applications? Well, yes and no! As we continue the search for the killer script, that “holy grail” of scripts which can do it all and never needs to be modified, we turn our attention to the wonderful world of XML! Every Scripting Engineer has a library of routines that hey have emerged over time. They accumulate over as the scripts become more refined with time and experience. You would think there would be nothing new under the sun, but from time to time someone hits on a particularly creative solution to a common call flow requirement.

I have to credit Steven Griffin, a true rockstar of a software engineer, with opening my eyes to the possibility of using a “QueueOptions.xml” file to specify parameters you might otherwise hard code in a UCCX call control script. I have learned from other engineers like Wesley Forvergne and Anthony Holloway how to build on this concept (these guys have all really advanced the state of the art IMHO) and create scripts that are extensible, supportable and flexible! Why have to write another script or launch other instance of a script just because the SLA, Menu or Schedule changed? Why not have a Script that can reconfigure itself based on parameters recovered from a configuration file, using DNIS as the file index? An inbound call to the contact center triggers a script which uses the DNIS to look up the appropriate configuration for the number dialed.

Maybe this DNIS differs from another DNIS only in as much as the On hours specified in the Schedule? If you have been using that “Day of Week” and “Time of Day” UCCX script step you have no alternative but to have either a bunch of “if” steps or creating the same script on another trigger so that you can have a different operating time. What an inefficient waste of processor and system resources! Why not just read in the Schedule from an XML file and use the same script for all your DNIS numbers, all on the same trigger? You can even reconfigure the Menu and Prompts, change the voice mail box, determine if you should play “estimated time in queue” or not and just generally customize the script on the fly!

XML is just a powerful alternative to OBDC type solutions. No special drivers, portable across operating systems, language independent and able to handle dynamic database changes. Your XML document can be updated dynamically as required through HTTP and other web based technologies. This makes it possible to integrate your call flow based on input from a website entry! How about SMS to XML? Think of the possibilities! I guess that is what we really enjoy about Contact Center scripting! Never a dull moment and limited only by imagination.

The video discusses the creation of an Xpath specification assembled on the fly and uses a string value to index the XML document. Great entertainment and fun for the entire family!

In search of the Killer Contact Center Script (UCCX or ECC)!

Posted on August 5, 2013 by DrVoIP

The “Killer UCCX Contact Center Script”

After your first 100 or so Contact Center Scripts, you begin to wonder if it would be possible to generate a “killer script”! No matter how many hours you sit with clients and do your very best to extract their call handling requirements, it just never seems to be enough! Generally, you have some block of professional hours to complete the script, test, train and turn up before “go live”. You ask the client for their requirements and “wish list”, then prioritize the list toward the goal of getting as much done as possible within the budget allocated to the project. You no sooner get the script up and operational and the client is asking for six options that never came up during the time you were discussing requirements. They were never even on the “wish list”! Last time this happened to me, I determined to write a script which would have run time options for the various script extensions I have seen over the years. Starting with a basic Generic script which had modules you could switch in and out to achieve not only increase functionality, but efficiency in both cost and time.

Route Type? Prompt and Collect!

Most call flow scripts can be reduced to answering an incoming call, playing a menu of options, navigating to a Contact Service Queue, finding the most appropriate human resource or managing queue handling while the caller waits for service. Sometimes there is no menu after the call is answered, and the call is sent directly to the Queue. At other times, we need to provide some “prompt and collect” for database look up prior to call routing. We are always looking at operational alternatives for time of day, day of week and holiday or emergency closings. This sounds like something we could develop into a general purpose call flow script, complete with generic record prompts in the language of choice. So the Killer Script contains a library of professionally recorded prompts and prompt segments for enabling you to assemble your own prompt!

Where are the IVR Prompts and professionally voice WAV files?

We long ago learned never to start coding a project until we had the actual recorded prompts and wav files in hand! How many hours of development time have been squandered because an attempt was made to code without the scripts. When the client finally delivered the actual recordings to be used in the script, they were different than the call flow we all signed off on during the requirements meeting! Don’t do it! Get the recordings done first. Then and only then code your call flow! This thinking gave way to a concept of numbered prompts! Again, you no sooner get the project on line and “go live” and the client is back asking if they can change a recording! Why not create a module that would allow the client to call into an IVR script, select the prompt they want to record, play it to confirm that it is the correct one, and then let them record it themselves! I started thinking about this after the first experiences in which the client asked for special closing recordings. The client would say something like this: “Sometimes we have a staff meeting and we need to close the queue. We want to play a special greeting to the caller letting them know we are in a meeting.”

CCAdmin to allow supervisors to Open and Close Queue with custom Closed prompt!

So we now have a Generic Call Flow Script that has an option for a Contact Center Administration and prompt management! The Generic Call handler offers some run time options that can be set at run time. They include a ROUTE TYPE (i.e., Menu, Direct, IVR or Transfer) that dictate how to handle the incoming caller. In fact, we can change the route type based on the DNIS or ANI, so the script actually changes its call flow to play a Menu or send the caller direct to Queue with each new call. We then created a Contact Center Administration module that would allow an authorized user to open and close a queue on demand by dialing into an IVR script. If you closed the Queue, you were offered the option to record a new closed greeting. Optionally, you could record any existing prompt by entering the prompt number. All of this done by an authorized user with a PIN number and not requiring the System administrator.

Queue management was another area in which a modular approach to scripting could enable a range of options. Do we play “your estimated wait time” or “your position in queue is” or just play music on hold? If they are in Queue awaiting an agent resource, do we offer them options like, “Press 1 to leave a message, 2 to schedule a call back, or continue to hold and your call will be answered…?” Not every client wants these options, but many want the choice. How do you make that option available without burdening the project with more develop hours? In fact you might want these options to change based on who called or what number the caller dialed. We determined to add a third module to our script library. We can now offer the call back option on module basis.

Clearly every call center is different. You will always need to modify your scripts. It is possible however, to create a flexible, reusable script that has configuration options or modules. It is also possible to make these options available at run time based on DNIS or ANI. There is no need to launch a separate script when you can reconfigure the same script on the fly to address the various call handling options required to manage a caller through a successful contact center interaction. Ask us about our generic scripts and save yourself a ton of money while paving the way for self-managed call center flexibility as you move through your business process! DrVoIPGeneric, DrVoIPCCAdmin and DrVoIPCallBack are all available for CISCO UCCX and come with professionally recorded generic voice prompts that can be easily branded. We also include supporting XML documents for Scheduling, Holidays and a Queue options template for changing call flow based on DNIS!

Killer Script Overview – Updated for 2019 Version!

The Core Root script is a single thread that enables both application level run time variables as well as “variables on the fly” through the QueueOptions.XML file. Typically the script will be trigger by one of the DNIS numbers attached to the script. This DNIS become strDNIS in our application and it is used to index the XML file to pull back all the variables for that specific CSQ. One of the variables that is returned is the strApprefix value. For example we have “CSQ_SandBox” for testing and it has a strApprefix of “SBOX”. This variable is prepended to objects like Queue Message Wave Files. In this way SBOX_QueueMessage1.wav and PTAC_QueueMessage1.wav can both be represented by strApprefix+”_QueueMessage.wav” in the same script! This also makes it possible to create Layouts that are pushed out to the agents.

The QueueOptions file contains all of the variables that you want configured for a specific CSQ. It sets options for offering Estimated Wait Time and Position In Queue. We offer the option of a call back without losing your place in queue. This has a variable that can be set to enable “record a short message to be played to the Agent before you call is returned” or to disable that option and move directly to collecting the target call back number.

Route Types (Direct, Menu, IVR, Debug)

Some CSQ’s require that the caller be sent directly to the Call Center. Others require the caller to navigate an IVR or MENU and the option strRouteType defines these options. If the caller is to be offered a Menu of choices the script loads the correct menu, again using strApprefix to bring back SBOX_Menu.aef at the appropriate point in the call flow. Likewise the caller can be directed to an IVR platform before the call moves to the call center.

The Killer Script is actually a series of scripts, documents, professionally recorded voice prompts and sample XML documents that you can copy, modify or edit to suit your call center CSQ configuration goals. All this for $295? What a deal, your average professional service company is billing scripting engineers out a $275-$350 and hour! If you have any scripting experience at all, you should be able to configure this script! Optionally, we can quote a fixed project fee to install and configure it for you!

Text Us at 929-292-8100 for details!