Business Logic & Automated Voice Apps: An Introduction

Here at Plum we take user experience very seriously. That’s why we want to help companies that automate phone calls to provide not only great user experiences, but a solution that’s easy to manage as well. Because if your voice applications are easy to manage there is a lot less potential for disruptions in service or errors in the user experience.

With this in mind, let’s talk for a little bit about business logic. Business logic consists of all of the intelligence about a business and/or their users’ accounts. Let’s say someone has banking, credit cards, and insurance all with the same bank. When they call the bank to find out if their credit card has any late fees there needs to be something in place to easily let the user choose the right option and get the correct information in return.

If the caller wants credit card info, but get insurance info instead, they’re not going to be happy. The intelligence and processing (i.e. those If/Then conditions) that go into ensuring the system pulls the right data for each request is called business logic.

What’s Possible?

So who is responsible for creating and managing that business logic? The answer is: it depends.

At this point we have to draw a line between what is technologically possible and what makes the most sense from app creation/management perspective.

Technically an automated voice application, like IVR, can handle business logic. But just because something can be done doesn’t mean it should. Building business logic into the application makes it very difficult to manage.

First, in order to get this type of application to work, a company needs to provide direct access to their customer information database. In essence, we’re talking about a data dump. The problem here is that any changes to the database mean that someone will need to go into the voice app and manually reconfigure it to match the new data. This is very time-consuming and expensive.

Second, thinking back on our end user experience, it’s really difficult to test an IVR application with built-in business logic. Really the only way to test out every possible customer permutation is to manually call and enter each choice to make sure it works. Failure to thoroughly test the application leaves it vulnerable to errors, which leads to unwanted user frustration.

So while it may sound attractive at first to build your business logic into your IVR, especially if you’re farming out the development of your voice application to an external vendor, in the long run this decision will be very costly both financially and in terms of poor user experience.

What’s Smart

If baking business logic into your IVR isn’t good idea, then what should you do when getting started with voice automation? The optimal choice is to build your own web service that is narrowly focused on the needs of your voice application and connecting your database to the voice app through an API.

That’s a lot to process so let’s unpack that previous paragraph a bit. All of those commands and conditions that find and locate the right information can be scripted and assembled into a library. Some companies may already have business logic, or libraries, or even APIs that they already use.

It’s tempting to repurpose these resources for your voice application, but for optimal results it’s best to create a new web service out of those pieces that narrowly focuses on the needs of your voice application. That way it will work more efficiently to present users with the right information.

This web service is something that you will want to host yourself. The reason is pretty straightforward: it’s a lot easier to manage your business logic and to make changes to it if you control it. When it comes to getting the right information to users, business logic is the most important piece of the system so it’s something that you will definitely want to have direct control over.

If your business logic does all of the heavy lifting, then what’s left for your voice apps? Their role is to present that information to your users. Let’s return to our banking example for a moment. Let’s say that our user wants to know if they have a late fee, and if so how much that fee is. The user responds “yes” to a question about whether they want to check for late fees. The voice app passes that request to your web service through an API.

At this point your business logic goes to work, identifying the right account. Ultimately it will return a “no” if there are no fees, or if there are it lets the user know that they do, in fact, owe a fee and tells them how much that fee is. Therefore, the information that is passed back to the voice app is the final response.

This setup ensures that your web service passes the minimal amount of information necessary to the voice app to get an answer passes. This is a case where less is more: more efficient and safer (because there is less risk of exposing sensitive data).

What’s Next?

Fortunately, when it comes to connecting a web service that feeds into your business logic to a voice application, Plum makes it really easy to do. Our products rely on APIs to establish these connections, which makes the entire thing much, much easier to set up and more flexible too. To learn more about how to get the most out of your business logic in voice applications, contact one of our experts.