Data Collection within an IVR is a feature we use within our Q-Suite, an Asterisk ACD System, to look up the customer via their caller id and associate it with a record already in the system.
I only briefly talked on this feature set and what it accomplishes for us, lets look at it in a bit more detail and a few other variations possible. In our scenario the main goal is to have the agent bring up the proper record quickly with the database lookup done by the IVR. The DB lookup is done in the IVR then the script page on the agent’s screen uses the information and seed a search to an external application.
- Direct DB lookup. A lookup to associate a caller with a customer list within the system. This would be a list of existing customer loaded into the system’s own database with the key usually being the caller id, but the key to match the caller to an existing customer could be any field if the IVR is configured to prompt for it.
- External API/web service. A lookup on an external system and associate the returned data with the caller. This can then be used by the scripts to provide the agent more data. Or to pass to the an external app within the script to save the agent from searching again. Depending on the case it may be best to simply pre-populate the search fields and have the agent submit after confirming the information or adding more once talking with the caller.
Using the IVR and collecting data is great as it tends to free the agent to be handling other calls while a caller navigates the IVR but can be abused and cause negative side effects. For example it can be annoying to the caller if too much data is collected which is not easier entered with a phone in the IVR. The goal should be to collect a small amount of relevant data and get caller to where they need to be. If passing to queue and ultimately an agent, make sure data collected that is required for the agent to know is passed along or accessible. I am sure we have all called systems and entered data only to be asked for it again from the agent. As I noted a confirmation of it might be required, but if the caller just entered their 16 digit card number perhaps just confirm the last 4 digits, name, etc. and assume the rest of the data is accurate when possible.
This post was delayed as I found another blog posted a similar topic just before my original planned posted date. So also take a look at the two-part article over at indosoftnotes.blogspot.com on IVR Data Collection.
In previous posts I have covered configuration options for ACD Systems and their Queues. Without the proper data it is difficult to verify the staffing are proper and configuration is efficient. While looking at reports to determine what has happened in the past is a requirement of any system, knowing what is going on right now is just as important.
Maybe you have a light indicator showing calls coming into queues or the queue levels like the Phillips Hue this is a good indicator of what is going on but does not show a full picture. This is where an ACD Wallboard screen comes in, perhaps it’s a large screen on the wall or viewed via the admin interface by any and all managers.
An ACD Wallboard can show the following information:
- Agents Staffed which shows how many agents are logged into the system and associated with the queue
- Agents Talking. A subset of Staffed but shows agents currently talking.
- Agents Ready. A subset of Staffed but shows agents ready and waiting for a call.
- Callers Waiting: How many callers are currently waiting unanswered in queue.
- Longest Wait of a currently waiting caller.
- Average Wait of the queue for the queue. This is usually over the last number of calls or a timeframe.
Usually there is a row or box for each queue and coloring can be adjusted to highlight queues that are in good standing or a concern depending on the rules at hand. This this information easily at hand it is easy to quickly respond to changes in call volumes which require live changes.
Even with the best planning there are times when callers are overwhelming specific queues causing wait times to grow longer than usual which could be over the expected SLA (Service Level Agreement). Perhaps a marketing campaign is going viral and the response is much higher than originally thought, or a new product just shipped and calls are higher due to activate or inquiries about it. Knowing this was planned the call center already expected more inbound ACD calls and adjusted the staffing levels higher, but this is not an exact science.
This case is where from an admin interface you need the ability to adjust the skills for a number of agents to change which queues they are handling with which priorities. This allows a currently lower demand queue to have some agents removed or able to cover both. This may raise the wait time in the lower demand queue but if done correctly can keep it within the SLA for that campaign.
With the Q-Suite this is possible with it’s advanced skills based routing and Queues. Adjusting any skill for any agent is easily done from a single screen on the fly in real-time without any action required from the agent.
With Asterisk ACD Systems, or any ACD Software, one has to take into account the agent’s behaviour. One issue that can happen is an ACD call is routed to an agent due to indicating they are ready but are not able to accept the call at that time.
They may miss the pop-up on screen prompting them to accept the call. Or perhaps they are On-Hook and are distracted and unable to answer the call in time. Answering the phone while in On-Hook mode or clicking to accept the call are both forms of acknowledgement which when received bridge the caller and agent together.
What happens when this acknowledgement is missed?
This will depend on the configuration. Systems will offer two key settings related to these missed ACD calls. First is how many times to allow calls to be missed, if this is allowed then the agent will go back to being ready for a call after missing the acknowledgement. The second setting is related to how quickly they will go back to being ready. It’s typically best for the caller experience to not put them back in automatically until the agent indicates they are ready, however some situations will have agents missing the occasional call and then it makes sense to put them back after a few seconds.
No matter the reason or configuration when these cases happen we still need reporting to let us know what is going on with the system and agents.
In previous posts I have mentioned the need to properly configure and staff queues to meet the needs of your customers. Using ACD Skills with priorities plays an important role.
Skills are initially seen as a way to get an agent logged into their proper queues. Which is true if all the priorities are equal. Using priorities on skills allows for fine grain control to ensure the best trained agent available will get the appropriate caller.
Lets take language as an example, but this could also apply to different products or categories being handled. With language lets say you have a three groups of agents. The first is native english speakers who also speak french as a second language. The Second is native french speakers with english as a second language. With the third being those agents who only speak english.
The first and third group would both have the “English” skill with a high priority. However the first would also have the “French” skill at a lower priority than the second group, the native french speakers, which allows them to help with the french queues during high call volumes. A similar configuration reversed for the native french speakers who also speak english would be setup so they can in turn help with high call volumes on the english queues.
Doing this makes the queues more efficient as there are more people staffing to help during the high times but priorities on the skills ensures their primary queue is still staffed and calls handled in a timely manner by the highest skilled agent available.
This can also be extended to supervisors who only occasionally take calls, perhaps during high volume periods to keep up with the extra inflow of callers. The supervisors can be set to lower priority than the agents so they would only get calls when no agents are available for the queue.
There are many other cases where skills and priorities can be used to meet the needs of the business case at hand.