Philip Fuller, President
First, thank you for entrusting us to deliver and support caller service solutions in 2008. On behalf of the entire VEXIS Systems team, I wish you, your families, colleagues and company a great holiday season and happy, healthy, prosperous 2009.
As I reflect on my 12th year at VEXIS, and my first as president and CEO, I am once again reminded that VEXIS is defined by its people, represented by both our loyal customers and our dedicated staff. This remarkable relationship helped us make some great strides this year, some of which are:
Most VEXIS customers in virtually every industry we serve must streamline day-to-day operations even more, as they both manage and minimize the disruption of consolidations, acquisitions and mergers. Our portfolio of products and services can help preserve and even enhance service levels, create a more unified user experience, and reduce costs.
Thank you again for choosing VEXIS Systems. We look forward to working with you in 2009 and beyond.
Jacob Martin, Director of Operations and Solutions Services
We began the year with a strategic plan to establish even higher customer service standards and increase the size and scope of our solutions services capabilities. A series of changes and improvements, some relatively small and others more significant, added together have produced considerable results.
Our first step was to evolve the VEXIS Interaction Process (VIP™) into a formal, documented methodology. To support a larger overall services staff, we expanded both our training program with a more extensive in-house curriculum as well as added external training and certification opportunities. And we have increased the size of our staff to strengthen our project and support teams and bring additional expertise to our services portfolio.
Professional Services revamped the Statement of Work (SOW), General Solution Design (GSD) and Detailed Design Specification (DDS) documents to give greater dimension and guidance to our projects. The larger team using these formal methodologies and documents has produced higher quality deliverables and reduced project lifecycles. VEXIS customers and employees have been enthusiastic about these changes, which take a more scalable approach that improves project efficiencies and produces consistently high quality results.
Support Services built the new Customer Portal with Web and Speech-enabled IVR capabilities that uses mobile messaging as well as outbound calling to create and manage trouble tickets. We integrated this with an upgraded trouble ticket system that includes a knowledge base and improved tracking, among other features. Together with our training initiative, we have been able to advance our interaction with customers to the next level. The results for our customers are a shorter mean time to resolve tickets and even higher customer satisfaction – and a working example of a multi-channel, speech-enabled VEXIS solution in action.
VEXIS Systems remains committed to quality and will continue to work to improve quality in all areas of our business including sales, services, technology solutions and support. The changes we made in 2008 have set the bar high – and we can’t wait to surpass it in 2009.
Richard Wolff, Director of Software Applications
In this issue we will explore the latest enhancement to the Envoy™ framework commonly referred to as “multi-client endpoint” support, a remarkable new feature. The enhanced capability to support multiple clients with various “message framing” types simultaneously is what makes Envoy™ so flexible and adaptable. Envoy™ Server now communicates with both “Envoy™-enabled” and third party custom client applications.
Envoy™ Client - In the past, the Envoy™ Server communicated with the Envoy™ Client. The Envoy™ Client is in fact very flexible and powerful – it can be called from many programming languages and can run in either thick or thin client applications. It can be used from single user “agent desktop” applications and also enterprise server machines that support hundreds of “virtual agents” such as an Interactive Voice Response (IVR) application server.
Custom Client - The Envoy™ Server can now communicate with custom client applications (i.e. applications that have not been specifically “Envoy™-enabled”). Custom applications are deployed throughout the enterprise in the form of thick and thin applications – and they too may be running on “multi-user” application servers and “single-user” desktops.
What is message framing? Envoy™ Server can communicate with Envoy™-enabled applications as well as custom applications speaking their own “message framing” types. The message framing of an application can be thought of as a “language” that each client uses to communicate with a server. So essentially what has been added to Envoy™ Server is the ability to communicate in many languages (message framing types) simultaneously, even with applications that do not have Envoy™ specific programming. Better yet, an Envoy™ Plugin running within the Envoy™ Server can be customized so that the same message (known as a “payload”) can travel from “Client A” using “language A” to Envoy™ Server and then could be forwarded to “Client B” that uses “language B”. Because a payload can consist of virtually anything – perhaps the result of some work the server does and / or the original payload that arrived at the server, one can easily see that Envoy™ Server is truly an “information hub” for various client applications.
Sounds great! But how can Envoy™ Server become a “message translator”? Envoy™ Server associates the message framing type (i.e. “language”) of the incoming request with the connection that is made with the client issuing the request. Envoy™ Server then uses this connection-specific association (“endpoint”) in order to frame the response properly. Simply put, Envoy™ Server “remembers” the language used to communicate with it and so it responds back with the same language.
Use the power and ease of use of Envoy™ Client with logical connection multiplexing, multi-threaded performance, and routing intelligence built into it or use the client application of your choice – and connect to Envoy™ Server for all your backend system data access. Call us to learn more.
Brian Smith, Director of Strategic Initiatives
Back in the mid 1980’s, I got my first real computer - a Texas Instruments TI-99/4A. While playing a game called “Alpiner”, I was precariously trying to move my climber to the top of a summit when a rock knocked the little guy off a ledge. As I started again towards the summit, the game blurted out “Onward and upward” in a slightly creepy yet human-sounding voice. “What?!? My computer is talking!” I had to find out what was behind this incredible technology. After hours and hours of reading manuals and poking around in the terminal emulator, I had put together a very rudimentary application that allowed the computer to speak whatever I typed. My friends and I would stay up until the wee hours of the morning making the TI-99/4A speak our names, jokes and poems, and every cuss word we could think of. Thus began my fascination of text to speech.
Text to speech (TTS) plays a vital role in the telephony sector. When designing an IVR application, the presentation tier is built by stitching together a series of pre-recorded voice segments called “prompts”. These prompts are typically recorded by the application developer during the development phase, and then re-recorded by professional voice talent just before production rollout. The recorded “application prompts” are played in a specific sequence which is decided by the application logic. For the presentation of dynamic data such as a date or dollar amount, the “application prompts” are paired with “system prompts”. System prompts are a large collection of pre-recorded voice segments such as numbers, months, letters, and other commonly used items. Consider this dialog that a typical IVR might speak to a caller:
“Your current balance is $425.33, and is due on 12/13/2008.”
It is assembled and spoken to the caller using 13 separate application and system prompts:
“Your current balance is” “four” “hundred” “twenty-five” “dollars” “and” “thirty-three” “cents” “and is due on” “December” “thirteenth” “two-thousand” “eight”.
Often the IVR application is required to read data back to a caller that is too dynamic and variable to be handled with system prompts. For example, an IVR may need to read back a street address or a person’s name. Can you imagine having a professional voice talent record every single street, city, and state in the U.S.? The task would be daunting, and incredibly expensive. Text to speech makes reading back dynamic information easy. But how does it work?
Let’s imagine that an IVR application has retrieved a street address from a database and needs to speak it to the caller. The text string retrieved from the database is “125 S. St. Louis St., Tulsa, OK, 74135.” The IVR application will send this text string to the TTS engine for conversion to speech. The TTS engine first normalizes the text and breaks the entire phase into a series of spoken words. It parses the text string and looks for punctuation, capitalization, abbreviations, and even determines the intent of the phrase. Without understanding the intent of the phrase, the TTS engine is not able to deal with homographs, words with the same spelling but different pronunciation. Think about our example above: “125 S. St. Louis St.” It is clear to us that the first “S.” is an abbreviation for “South”, the “St.” before “Louis” should be read as “Saint”, while the “St.” after “Louis” should be read as “Street”. We know this because we understand that this is an address, and we can logically make assumptions about abbreviations and homographs based on what we know about the scope of street addresses. The TTS engine must understand these same rules in order to correctly pronounce the phrase. Invariably, the TTS engine may sometimes misunderstand the intent of the phrase. When this happens, a developer can help out the TTS engine by labeling the phrase with Speech Application Programming Interface (SAPI) commands or the newer Speech Synthesis Markup Language (SSML) tags.
Once the intent of the phrase has been determined and the text normalization and homographic disambiguation is complete, the word segments are broken down into the individual phonemes and sub-phonemes for proper pronunciation. In fact, a text to speech voice model is actually made up of thousands of phonemes recorded by a real person. The system produces the resulting prompt with these phonemes, giving the voice the proper tonal characteristics for gender, pitch, prosody, and inflection using voice models provided by the TTS manufacturer. In fractions of a second, a TTS engine takes a text string and returns an audio segment which is then played back to the caller.
The sound quality and realism of text to speech has improved exponentially over the years. The latest TTS offerings from Nuance are available in multiple languages, both male and female, and have the ability to emote and punctuate particular words and phrases by using SAPI or SSML markers. Custom dictionaries can be added to handle difficult words or abbreviations that are unique to the application. Text to speech is quickly becoming a formidable opponent for human voice talent. In just a few short years, the two may become indistinguishable to IVR users. As my little TI-99/4A would surely agree, text to speech technology has truly gone “onward and upward”.
Brian Smith, Director of Strategic Initiatives
Restricting TCP/UDP Ports on IVR/CTI Systems. Occasionally we receive customer support requests to assist in identifying the TCP/UDP ports used by their IVR or CTI solution. This task is usually driven by a security audit or the need to comply with specific security rules of the customer, parent company, another vendor, or a governing body for the customer’s industry. While VEXIS Systems has collected plenty of information related to TCP/UDP port utilization on the systems we integrate, each customer implementation is different and therefore we strongly encourage an exhaustive audit prior to restricting port traffic at a network level. PBX data communication, text to speech, speech recognition, host, database, and other components to your IVR and CTI solution will all utilize specific TCP/UDP ports, and all are critical to the successful operation of your solution. Should you require an audit or restriction of network traffic, please consult with VEXIS Systems Support prior to making changes.
Alternate Edify Versions for Development and Production
A number of our customers have older versions of the Edify EVIP platform running on development systems, while their production servers are running the latest release. The Edify IVR platform has consistently delivered the ability to recompile applications written with a previous release on systems of a current release with little or no issue. However, regressing an application from a new version of Edify back to an older version can be very problematic and is not advisable. When our customers engage in an Edify version upgrade project with VEXIS, we coordinate the upgrades for all customer systems, including production, staging/test, and development workstations. Keeping all Edify systems at a consistent release, including patch levels, ensures code compatibility from development to staging to production. If you are running a mixed-version Edify environment today, your VEXIS Systems Account Consultant can help work out a plan to bring your systems up to date.
Call Transfer Timing Issues
We have observed a few instances of PBX software release upgrades affecting the IVR’s ability to transfer calls to a CSR. This typically occurs in an environment where the IVR and PBX are interconnected through an OPS/FX tie line, or some other protocol that uses a hook flash and DTMF digits to transfer a call. In these circumstances, we have isolated the issue to the required timing of the hook flash and delivery of the DTMF digits to the PBX. The required steps after the destination number is sent (wait, hang up, a second hook flash) can also be a factor. To ensure uninterrupted service to your customers, please notify VEXIS Systems prior to any software upgrades to your PBX so that we can advise of any potential changes required on the IVR.
Your annual renewal fee provides the most cost-effective method for supporting your systems. Please make it a priority to remit your annual support payment on-time to ensure there is no lapse in service. Annual support renewal payments are due by December 31, 2008.
This newsletter is designed to provide you with useful support, technical and key topics of interest to you in a fast and efficient manner.
Let us know what you’re interested in seeing future issues. The goal is to make the results you get reading this as worthwhile as possible for your time.
Call 918-663-8080 and say “Support”.
Call 918-663-8080 and say “Sales” or email firstname.lastname@example.org