When you’re creating a new IVR, you have two choices; use a simple-drag-and-drop solution that’s quick but limited, or spend lots of time and resources hand-coding it from scratch. Neither option looks great, but we think there’s a better way.
Building an IVR that delivers a truly conversational experience – while still meeting business objectives – requires a lot of coding under the hood.
Developers tend to look at two options when building a new IVR app: a ‘no-code’ IVR development tool with a drag-and-drop interface that hides the underlying programming complexity, or full-on hand-coding in VXML (Voice Extensible Markup Language – an open-standard markup language that most voice platforms use).
In truth, neither solution is ideal. A drag-and-drop ‘no-code’ solution is essentially a call flow editor (if you want to see why that’s a problem I recommend taking a look at our recent post on conversations versus call flows [insert link]) and will enable you to build 80% of your new system very quickly and easily. But the final 20% – the 20% that really improves experiences and delights customers – can be extremely difficult or even impossible to create and deploy.
And the word final really does make a difference there. All too often, we see companies steam through development using an off-the-shelf no-code solution, only to arrive at the end and find that not only can they not use the solution to add the functionality they want, but that the proprietary nature of the solution means that they can’t hard code extra features in either.
The alternative? Hand coding everything yourself from the ground up. Full-on hand-coding is great if you have the time and money to spend on it, and a battery of skilled programmers in-house. But as soon as something needs changing and there’s no one around to code it, you’re stuck. And if your one VXML guru leaves the organisation, well…
We think there’s a better way: Low-code.
In a recent article¹, Forrester Research called out how important “low-code” has become as a platform for creating and deploying new enterprise applications. According to them “Low-code platforms are rising as an alternative for developing customer-facing apps. Initially targeted at speeding all projects, these platforms are finding traction in the age of the customer’s heightened priority for customer experience software.”
The concept is simple, intuitive tools and frameworks make creating the core of your apps easy, but you retain the freedom to hand-code specific features and capabilities.
In the voice channel, what we do is very similar. A low-code solution makes building the core of the IVR as quick and simple as possible using pre-built or automatically generated modules, but offers the flexibility to hand-code additional features using industry-standard languages such as Java instead of having to stick with the often troublesome VXML. It really is the best of both worlds.
Coding in a recognised language like Java doesn’t just make it easier to find people with the skills you need to create, deploy, and maintain your new IVR app. It also enables you to benefit from all of the recent technical advancements in modern application development – like automated builds, testing and deployment.
No-code won’t get you the IVR you want, but there’s no need to battle with a primitive markup language like VXML or write the whole thing from scratch, either. Look for ‘low-code’ tools that let you build a conversational IVR fast, but keep in mind that as with any other tech purchase, not all solutions are alike.
Find the tools that are right for your organization by asking yourself:
Does the solution offer a simple way to create your “80%” (the features that you see as core, or essential to your IVR experiences) without making the last 20% impossible and causing excessive restrictions and lock-in?
What language(s) does the solution enable you to program in? And what other benefits are there to coding in that language? Can you use source control and do automated builds, deployment and testing?
Does the solution line up with the coding skills you have in-house, and if not, how easy will it be to bring those skills in?
¹ New Development Platforms Emerge for Customer-Facing Applications, Forrester Research, August 6th 2014