So your organization has transitioned to open standards VXML … what’s next?
Interactive Voice Response (IVR) has been assisting Call Centres in providing self service capabilities to their customers for decades. The voice channel has provided automated self service solutions to customers far longer than most other channels and had operated on vendor specific telephony platforms – some of whom no longer exist today. Large and small IVR platform providers invested years of Research and Development to refine their IVR application development tools. These tools provided a graphical user Integrated Development Environment (IDE ) generating proprietary application languages that would operate only on their IVR.
During this period, best practices were developed to incorporate these tools into daily business processes. Suddenly, organizations were faced with End-Of-Support and End-Of-Life for these products. Early adopters and technology innovators quickly transitioned, while other organizations had no choice but to adapt and embrace what the trending market and newer capabilities had to offer – Voice XML.
Voice XML was pioneered by a group of industry leaders. Their goal was to provide an open-standards based development language for IVR applications in an attempt to address the challenges that most organizations faced for years of being tied down to a proprietary IVR vendor. Although the ingenuity of Voice XML may seem to have anchored a solution, the underlying issue of continuing to develop in a proprietary environment remains doubtful.
With the birth and evolution of Voice XML more than a decade ago, many new IVR companies started to emerge from every corner of the globe promising to deliver IVR solutions that would eradicate cross-platform incompatibilities. Organizations were led to believe they would no longer be tied down to any one specific vendor ever again.
Adversely, larger telecom platform providers assembled their core capabilities in tandem with other innovative companies, buying and incorporating their technologies into their own. As a result, VXML offerings from these major vendors would not only include a VXML-compliant browser, but would come complete with a graphical user IDE. This offering allowed new and existing IVR developers in an organization to write VXML applications more efficiently without ever having to write a single line of Voice XML code. Essentially, the same type of graphical user IDE’s that were made available by the proprietary IVR tools developed from the early days were once again resurfacing.
Depending on the VXML IDE, product offerings range from tools that will produce VXML code; others may produce runtime JSP/ASP scripts or servlets; while others will actually produce their own proprietary language that when equipped with their own proprietary interpreter, will dynamically generate VXML at runtime.
Regardless of the VXML platform or IDE, most organizations are facing the same issues with new implementations – IVR application design and cross-platform compatibility.
As a Senior Executive, Director, Manager, or developer of an organization, you may have already endured such challenges. The vendor you have selected to implement your IVR solution has promised to resolve incompatibilities by engaging their Professional Services and/or offering expensive training programs. In all cases, services and training that continues to be – proprietary and costly.
Organizations need to implement their IVR application code so that they’re no longer tied down to any one vendor. Taking advantage of what Voice XML was intended to deliver will fully restore the appreciation of true cost of ownership.
Following proper application design will dictate how the overall solution should be architected and developed. This will result in reduced application code that could be reused and recycled for years to come even as the VXML standard evolves.