As long as there have been contact centers utilizing UCCX, there have been audio prompts. As an engineer, you know them because you have probably had to help create them, remaster them so that they actually work or even in a pinch record them yourself. We all have at least one number that we can call and hear our own voice welcoming callers to a bank, bakery or auto repair shop. Prompts are a necessary evil, but why are they so evil? Why didn’t Cisco give us a recording application? Why did they point us to the horrible “Media Master” interface in Unity/ Unity Connection as our default option? While I cannot answer those questions, I can provide a better solution.
A Prompt Management Application…
Think about it, we have everything we need. UCCX provides annunciation, menu infrastructure and the ability to build/record files right out of the box. We have everything we need, we just need to put it together.
While the purpose of this blog is not to give, but rather to inspire, there are places online where you can find prompt management applications that others have written. I’ll show you the ins and outs of mine in the hopes that perhaps you’ll want to build your own.
After the Start, Accept (if you don’t know why these two are important a UCCX basics course is probably your first best bet) we set a temporary path in the memory for our new prompts (shown above, click to enlarge), just because you record a prompt does not mean you have to save it. This application bases prompt save names off of 4 digit numbers. Friendly names for prompts are great but not all that useful from a telephone keypad. After defining that temporary path I ask my callers for a PIN, this is a simple authentication step that UCCX has built into its arsenal of objects. If you want to get more secure, you can base the authentication on a User ID and password from the UCCX user list but I don’t have a need for that here. TIP: If you make the PIN a parameter in your configuration, you’ll be able to change it easily from the application page in UCCX.
Once a successful PIN is entered, I give my caller two choices; record a new prompt or listen to an existing prompt. To me, this is a big deal. There are some applications that only allow the caller to record a prompt, that is fine, but for me the ability for the caller to listen to an existing prompt before changing it makes the application much more powerful.
The image above (click to enlarge) shows the listen section of the application. If you store your prompts in the default paths i.e. en_US or whatever language you need this is very simple and straight forward. If you store prompts in multiple hierarchical folder locations you’ll have to call those locations out in your script. As you can see, this works with a formula that takes the prompt name (number) entered by the caller and adds .wav to the name.
Recording prompts take a bit more programming but as you’ll see below it is relatively straight forward (click to enlarge).
If the caller wants to record a prompt, the first thing that this application does is ask them to record it. You could ask for a file name first but technical order of operations is to create and then save so this way makes more sense. Once the caller records their prompt, the application allows them to replay, re-record, give up and go to the main menu or save the prompt. If they choose to replay (the importance of that temp directory from before) we replay the temporary prompt from memory. If they choose to save, that is where the magic happens.
As you can see above (click to enlarge), the save function of the application utilizes several different parts. First, we ask the caller for a prompt name (number). Besides being practical from a telephone keypad, the prompt numbering method allows you to take a list of prompts and number them for your vocal talent. As they go through and record and save, they are creating a script that can be referenced weeks, months and years down the road as verbiage from the prompts has to change. Once the prompt name (number) is entered we play a confirmation and ask the caller to confirm the save. If confirmed, we write the prompt in the prompt directory (default or specified) and the action is complete. To make the saving of the prompt possible, we do have to give the application administrative rights. What this means is that we have to reference an administrator username and password in the script. TIP: Create an administrator user and password that is exclusively used by your script, do not use your primary admin user.
The last screen shot that I want to share is the variable list from the prompt management application (shown below, click to enlarge). I’ve blocked out usernames and passwords but you get the idea. You can see all of the prompts you need for the prompt management application, this gets into the philosophical discussion of which came first; the prompt or the prompt recording application.
Once your script is complete, you simply create a UCCX application and build a trigger.
While it takes some work to build initially, you then have an application that you can deploy on all of your UCCX builds in the future. It is a quick and easy way to give your customers or stakeholders value-add or at the very least impress someone and I promise it will make your life easier as you administer these systems going forward.
Thanks for reading, if you have questions post them below and we’ll have a discussion.