When you have a previous relationship with your client, it’s important that this be reflected in the customer experience. Often, the data concerning the client is available in a separate system from your call center ACD software.
We’ve touched on the topic of using external data in previous blog posts, notably Populating Client Information to Agents in Your ACD – Part 1 and Part 2. In this post, the topic is solely external data.
Keeping data in a central location can be an effective way to ensure data stays in a consistent state, rather than being replicated and updated separately. It’s important to make sure it’s available when and where needed.
In the Dialplan
While the call is still in the dialplan, there are a few methods you might use to associate external data with the call in an Asterisk-based system:
- Asterisk Gateway Interface (AGI)
- Asterisk Manager Interface (AMI)
- DTMF from user (the user is an external data source)
Asterisk Gateway Interface (AGI)
The AGI method is really a combination of methods to pull data. Since an AGI can be any sort of executable program, an AGI can return data from an external database, pull results from a web service, or even calculate values based on other information already available in the call. This flexibility is the biggest advantage of this method, despite the potential complexity. The biggest drawback can be response time. In most cases, the call has to wait for the AGI to finish. When calling a web service or consulting a database, any delay in receiving a result delays the processing of the dialplan. If the web service being called takes 30 seconds to return, that’s 30 seconds the client is waiting before they can enter a queue, hear a prompt, or do anything else.
AGIs are easy to set up, you must simply put your program in the Asterisk AGI directory. This is usually /var/lib/asterisk/agi-bin. Once it’s there, it can be called in the dialplan using the AGI command and passing any parameters. The AGI can also access a wealth of values that are already set for the current call. For common tasks such as calling a web service, your dialplan builder may already have an AGI that can be used. Many providers now offer external APIs for their services. Functionality can range from a large database that provides multiple pieces of data in a single call, to something as simple as a Caller ID Name service. These are easy to access via a web service AGI.
Asterisk Manager Interface (AMI)
Using the Asterisk Manager Interface to push data is not for the faint hearted. Connecting to the AMI allows events to be monitored, and in theory if you note an event you can respond to it via the same interface. Unlike the AGI, if you want to have data set at a point in the call, the call won’t stop and wait for it. You either have to guarantee that the proper AMI commands will be sent at the appropriate time, or you have to build something into the dialplan to wait until the correct values are set.
Using the AMI is not something call centers usually do for themselves, but sometimes system integrators will hook into it. The AMI is the most efficient way to actively monitor Asterisk and calls all the way through live on the system. Anything else would normally require customization of Asterisk or a lot of monitoring of files and processes at the operating system level. It does allow sophisticated software systems a window into your system, so it does require caution but provides powerful access.
DTMF From the User
Really, the most common method used is the third. Using the client as a data source is efficient to do, but does not improve the customer service experience in most cases. Asking the client to enter a 9 digit account number is prone to error, as well as memory lapses. If you are asked for such data in a phone call, it usually means you have had to look for old invoices or through your email. Very inconvenient. This is a method that is not recommended if other methods are available, but it can be a good fallback if another method returns an invalid, confusing, or non-result.
The biggest limitation to user-generated data is the interface. For the most part, the interface is limited to the common keys present on telephones – 0 through 9 and the * and # keys. Voice recognition is a possibility, but it can be difficult to use, and accuracy becomes a bit of a problem. In a voice call, you can’t count on additional interface options being present.
At the Agent Screen
Once the data has been received, you still have to do something with it. When you’re branching in the dialplan based on what data is received, it certainly makes sense to get it while the call is still there. However, you often need to get this data to the agent handling the call. In that case, it can make sense to access this data via the agent interface. The agent interface should offer a client interaction script that can pull data from external sources. The most common methods to do this would be:
- An external web page
- A database query
- A web service
- Asking the client directly
External Web Page
The simplest way to present external data to the agent is to incorporate a third party web page into the agent interaction script. This may be done in-line in the agent script itself, or as a pop-up or open in a new page or tab. Usually some identifying piece of information is used to start the process, such as an account number that was pulled out at the dialplan stage, or the client phone number. This method has the advantage of being easy to incorporate into a web-based interface. It can also allow the agent to update and save data directly to the external source, rather than complete the call then have the information synchronized at some other stage.
When using this method, testing has to be done to ensure that some property of the external page doesn’t interfere with the calling page. For instance, we’ve seen instances where the external CRM being used changed the page to automatically go full screen. This completely disrupted the rest of the web interface, and meant the page could not be used inline. Other complications are certainly possible.
Database Query
Using an external database query to pull data lets you go straight to the source and get the most up-to-date version of the data. Most call center managers are not familiar with databases, so this is something that would have to be done in conjunction with more technical personnel. Also, there are a few ways to write the SQL and any number of possible return values, so this can be limited to one value per request.
One gotcha with using external databases is that the database and drivers often have to be defined at the OS level. This makes configuration an operating system level issue in order to make sure the drivers are present and configured. In cases where frequent accesses of information from a single database are being made, this can be a good solution, however.
Web Service
Just like with accessing data in the dialplan, web services are quickly becoming a preferred way to get external data into the agent screen. Providing an external API accessible via HTTP or HTTPS can be safer and more secure than providing external access to a database, and allows processing of the information as needed. There can be a few technical challenges to making this method work, but once it is, the flexibility and efficiency gains can be tremendous.
The biggest advantage of this method is that web services are much more easily customized. Implementation doesn’t depend on specific configuration or drivers on the client servers. Hosting and implementation details are completely separate from the ACD solution being used. The Cloud can easily be utilized to provide such services.
Asking the Client
Having the agent ask the client for data is a much better option at the agent interaction level. The limitation is no longer the keypad, and agents naturally do speech recognition very well. The biggest disadvantage to this method is the time and annoyance factor. It can take time to go through all the information needed. Callers do find it annoying when they are asked for information that they assume the call center agent already has. When that information already exists elsewhere, it’s faster and more efficient to gather it in one of the other ways.
In the end…
A solid, comprehensive contact center software solution should offer many ways to pull data from external sources. The solution can be simple, it may be complex, but ultimately making sure the data is there when the caller is on the line is how you are going to ensure a smooth customer interaction.