ACD IVR Feature: Data Collection.

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.

Connecting Call Center Agents

It looks like there’s a common theme running through recent blog posts. At the Indosoft blog this week, I wrote “Remote Agents in the Modern Call Center” discussing connecting at-home and remote groups of agents to a call center.  This seems like an obvious expansion of the Cloud to call center concept.

I had originally considered talking about connection methods in my post, but at the last moment cut it out as not being as important. That is a topic that was covered last Friday by Shaun, who wrote “Connecting Agents to the Call Center ACD” which talks about the types of devices an agent can use to connect in.

A couple of weeks ago, Brian wrote “Agent Connections With an ACD System” which discussed on-hook and off-hook agent connections, as well as VoIP vs. dial in or dial out connections for agent phones.  Between all three posts, I believe the topic of connecting agents to a call center is pretty well covered.

ACD Queue Features useful when the Caller Abandons the Queue.

With today’s busy world callers are in a hurry and want have their call handled promptly.  However when calling during high call volume periods they may not wait in queue until an agent is available.  In a recent post I talked about core ACD Queue features but lets look a few abandoned queue calls features.

Call Back – as described in my previous post gives the caller an option to leave a callback number and have an agent call them once available.  The benefit here is the caller is allowed to disconnect and not feel their time is being used up waiting in queue.  One potential issue is when the agent calls them back their phone could be busy or they are unable to answer it.  In these cases ensure the re-attempt rules are setup so the caller doesn’t get lost and is still called back in a timely manner, while not re-dialing to often.  A message on their voicemail will help to avoid this.  This is not a true abandon call as they used a process to leave the queue.

In the cases where the Call Back feature is not enabled or is but not used by the caller it may still be desirable to follow up if they abandon out of the queue.  When configuring the system for abandon calls there are a few options:

The abandon calls stays in the queue and keep position.  This means their call is handled in the order they called in, so it will follow the ACD parameters setup for that queue.  This allows the agent to attempt a call back with the CID or other information the IVR collected information may collected prior to the queue.

The abandon calls moves to another queue.  This means their call is moved to another queue which allows for different ACD parameters to distribute the call. This can allow abandons to be a lower priority but we want to get back to them in time, so the center is setup to prioritize the live call queue and the abandons get handled during lower periods.  Alternatively a different set or subset of agents based on their skills will only handle the abandons.

In both of these situations you may want to enable deduplication of abandons.  When enabled if a caller calls in and abandons then does this multiple times before their first call record is handled they will only have one position in the queue.  For productivity it makes sense to have this enabled so agents are not wasting time dealing with repeated records or worse two agents calling the same caller back due to two abandons in the queue with their info.

Agent Connections with an ACD System

ACD Systems at their core provide a method to connect a caller to an agent.  Lets look at the options for the agent side of this connection.  Traditionally the Off-Hook nailup was the way to accomplish this.  This works great for a dedicated agent who is taking calls from ACD queues one after the other at a high volume call center.  It’s more efficient in that case to stay Off-Hook and save on the time of hanging up and answering the next call when the system can just bridge you to a new caller once you are ready.  In my last post I looked at our in-house case where our support department handles inbound requests in a unified communications configuration.  This use case is not call after call, but they will handle a call then an email or ticket so staying Off-Hook is not desired and this where On-Hook nailups comes into play.  On-Hook allow the agent to hangup their phone device and it will then ring when a new call comes into the queue.  Which makes it better for cases where there are breaks between calls or other tasks to do.

This gives us the two primary approaches for nailups, which are On-Hook and Off-Hook.  How does an agent get linked into the system to do these?  Traditionally we would see a local extension device directly connected to the ACD System as the nailup target.  So this extension would function as described above for either On-Hook or Off-Hook.  However there are more flexible alternatives as not everyone is able to be local.

  • VoIP extensions.  These would appear like any other extensions but a user would have a VoIP device (Smart Phone, Hard Phone, Soft Phone) almost anywhere they want to work.  This requires a decent internet connection and a secure way to connecting to the system.  Once connected the VoIP extension should appear and function as any of the local extension devices.
  • Call Out/External. This feature allows the admins or agent to provide a phone number to call the agent.  This mode can work for both Off-Hook and On-Hook.  With On-Hook one does need to consider the delay to ring an outside phone, as sometimes this will add a second or two before the agent will hear the ringing and answer the call.
  • Call In. This feature would use a DID and IVR which the agent would call into and once they entered the authentication info a valid nailup would be established.  This mode works for Off-Hook as the agent is the person to initiate the connection and needs to keep this connection up while they are working.

High Availability for Large Asterisk based contact centers

Cloud based call center software cater to very large systems. Asterisk is by far the most widely used telephony platform. As a natural evolution, the use of Asterisk in both Cloud and large premise based installations have come a long way. Technology for call center software is to some extent driven by the ‘assemble and build’ mode where various accessory technology element available in software form come together to deliver the final solution. Call center software depends on the underlying PBX technology and other technologies for web, database, SIP, and redundancy. Continue reading “High Availability for Large Asterisk based contact centers”

Load Balancing on Multiple Asterisk Servers

Asterisk clusters

Load balancing in Asterisk can be an overloaded term. In some cases, it refers to spreading calls to multiple servers. In others, it refers to calls made outbound. There are other cases as well. The two cases mentioned are two that are not handled by Asterisk out of the box, and additional software may need to be introduced in order to handle them. In multi-server Asterisk call center installs, load balancing allows calls to be distributed more evenly which prevents overloading any particular server. Continue reading “Load Balancing on Multiple Asterisk Servers”