CRM or data integration aren’t things that you often associate with your inbound IVR. That usually happens at the agent screen level. Sometimes, it’s handy to be able to pull data from an external data source and redirect the call based on the result.
Of course the simplest source of information is the caller themselves. Sometimes the caller can provide information to determine where the call should go. Entering information via DTMF , or even voice commands. Yet sometimes, that’s not the case.
As an example, Indosoft added an option to the Q-Suite Visual IVR Builder to do a lookup on a simple database. A large national organization needed this. Most calls go to a local franchise. Only in cases where there is no local franchise were they to go to the call center queue. The caller enters their postal code. A lookup on the postal code lets the dialplan know whether to transfer the call to a franchise or stay in the queue. If there is a franchise, the call gets transferred to its phone number.
That was easy to put into the product. It just returns a row of data from a static database into the dialplan based on a single input. There are hundreds of possible use cases for that.
Sometimes you need to do more processing. Like when you need to pull information that changes from moment to moment. If you want your client to get live shipping information, you have to update your database a lot. There, you want to hit an external database or method of generating data.
Accessing an external database is little problematic in itself though. Asterisk doesn’t have a lot of drivers for different databases. Some databases just work better with Linux than others. MySQL works well with Linux, and works well with Asterisk. MSSQL, on the other hand, does not integrate quite as well. You may also want to do processing of the data before you send it back rather than doing a direct database call. In those cases, it’s usually straightforward to set up a remote web service that you can call.
Using a simple XML format, it’s simple to construct a request and receive a response. This is why the Indosoft Visual IVR Builder includes a web service component. This component sends dialplan variables as parameters to the web service call. It parses the response and stuffs it into variables in the dial plan. Once you sent the request and received a response, you can go ahead and use the data in your IVR.
Implementation on the Asterisk side is just an AGI. Languages like Perl or Python include many libraries for handling XML and HTTP requests. Once you know how the requests and responses should look, creating the AGI is as easy as creating any other.
This approach allows you to do a lot. One case we’ve seen is checking to see if the number already exists in the client database. If it does, then another call sends the client number to the CRM to tell it that the client has called into the system. If there is no record for that number, a new record can be created in the CRM and the agent will see that this is a new caller.
One problem you sometimes see with a web service is a long access time. This can happen if:
- The domain name system (DNS) is down
- The web server is busy
- There’s a routing issue from the Asterisk server to the web server
The web service request can stall or even time out. Be sure to set Music on Hold on the channel before you make that request. The call can’t proceed any further until the AGI finishes. But, the caller may lose patience and hang up before a response.
If the caller does hang up, you can repeat the web service request in the hangup extension of your dialplan. If it’s important that the web service be called in every case, you can guarantee that. It can be helpful to notify your CRM that the client called in but never reached an agent. That way someone can check on the client and see if there is an issue.
This comment has been removed by a blog administrator.