In search of the Killer Contact Center Script (UCCX or ECC)!
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.
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.
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.”
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!