Posted on

How to Avoid using a “Courtesy Disconnect” as the IRS Calls it.

Tomorrow is the IRS tax filing deadline if you live in the US. If you call for help and their system is overloaded it will hang up on you, which they call a ‘courtesy disconnect’. Which brings me to back to a recurring topic on this blog and others which boil down to mistakes in IVR design.

If you haven’t seen the clip of This Week Tonight about the IRS take a look. The ‘courtesy disconnect’ segment starts around 2:23. But read on below for some suggestions for dealing with an overloaded system. Due to language this is clip is not safe for work:

[youtube //www.youtube.com/watch?v=Nn_Zln_4pA8?rel=0]

So it’s understandable that near the tax filing deadline the IRS would have a higher than normal call volume. Something that can happen to any company which should be planned for and tested prior.  Not being in the US I have never called the IRS and have no first hand experience but after searches and reading a number of articles it sounds like they are hanging up after a person has been waiting for a time. Of course the IRS can get away with this as their customers can not leave and go elsewhere. But if they wanted to improve customer relations they could implement this differently. I would suggest any of the following to improve similar situations:

  1. Max Caller Limit on Queues. This ensures the limiting is done prior to the caller waiting and any caller over the limit will hear a message to call back at a later time.  Of course one has to be careful here if the queue times out and sends to another we could end up in a situation like the IRS is doing and hangup up after a caller already waited. So it should only be on the first queues a caller can enter.
  2. Enable Queue Callback Feature. This is where the caller in the queue is offered to leave a callback number and is later called back, usually keeping their position in the queue. Be sure to combine this with option 1 as having thousands of callers leave a callback number but never get a call is just as bad as a courtesy hangup.
  3. Common Questions and Answers. Often callers have the same question and if the IVR can provide these answers it can save the queue and staff answering those calls.  This is especially useful in cases for general status which could be due to a temporary outage of a service for example.  These can and will cause an influx of callers all asking the same question until that’s resolved.
  4. Higher Staffing Levels. Not easy as it often requires hiring new people and that takes time.  However in this case it’s known this time of year will have increased call volume so having more staff to answer the calls is the simple, although not cheap, answer to improve the situation. Just ensure your system is capable of scaling to the needs and the hardware can power it. Alternatively go for a hosted system to avoid the hardware costs for a yearly surge which I am sure drops significantly the rest of the year in cases like this.
Posted on

Leveraging APIs provided by an ACD System

In a number of previous posts I have mentioned APIs in passing. Sometimes it’s the system calling an API of an external application while other cases are using the APIs provided by the ACD System.  While most systems will offer some level of API integration it can vary greatly, which is why it’s important to know what you are looking for in terms of APIs.  Lets look at the possibilities with the various levels of provided APIs that could be leveraged in an ACD System.

  • Data Management/Manipulation — this is often the first level of APIs a system will provide as it’s the most common requested. These APIs would provide ways of loading data into the system like contacts or user accounts. It often helps with data synchronization between systems, take the user account for example perhaps they are all managed with one piece of software and re-creating them in the ACD System is a duplication of work and manually doing so can cause inconsistencies. Using an API allows for this to be automated and if any new or user changes are done in the main user system they will be pushed out automatically.
  • System Control — this is typically the second level of APIs a system will provide as it is a bit lower and allows external control of various components. This type of API can provide a wide variety of options which could be pushing the changed data to be active/live on the system, logging out users, changing queue properties, etc. Or even as low-level as restarting a service, moving a service from one server to another for maintenance, etc.
  • Developing a Custom UI — this requires a full suite of APIs that allow full control and functions that the ACD System’s UI can do. Often a business will require an ACD System to integrate tightly with a current application and this can often be the best solution.

The Q-Suite has an extensive list of APIs which allow all the levels mentioned above and have a number of customers who have developed a custom agent interface.  While most if not all functionality provided by the APIs is available from the admin or agent screens it’s often more productive to integrate these calls with other systems to improve the desired workflows.

Posted on

Efficiently Routing Inbound Callers with Data Sharing

Companies which operate all their systems independent and keep the data in silos are often overlooking important efficiency which comes with data sharing between these systems. This can certainly true for Inbound ACD systems not linked to external applications which make the system less dynamic and user-friendly.

There are a few common ways to do this with a modern ACD Enterprise level solutions.

Loading the Contact List into the ACD System’s internal database. This allows a quick lookup to be done via the dialplan components to the internal database which can contain the information the agent needs right away. Loading can be done periodically uploading the list by file to the admin interface or by integrating with an external system via API. Using the API minimizes delays by allowing almost instantaneous sync by an automated process. Of course if the list is mostly static perhaps manually uploading is acceptable.

Remote API Call. Would be a remote call to another system’s API to preload some data at the time of the call. This can be done at various times with one common one being within the dialplan when the Remote Call is done to preload some data and/or route the call. This can also be done later while the call is on the Agent screen but at this time it’s already to late to route the caller to another queue automatically but still a valid case and is often paired with the dialplan lookup to load more details the agent needs.

Just in Time collected data from forms online. This allows skipping a portion of the IVR, redirect to special queues with skilled agents ready to talk, or just pre-populated on the agent’s script to save time on the call. Allowing the agent to get back to taking another call sooner and caller appreciates the shorter time accomplishing what they called for. The form could for be sales or support, for example, with the main DID can being common for those who did and did not fill out the form but anyone who has is directed to bypass a portion of the IVR or a special queue. The system handling the form can either push the data to the ACD System’s database or be available via a Remote Call as mentioned above.

These are just a few ways to bridge systems and make a companies data more accessible. Most companies will not get or want to go as far as true Open Data but freeing the flow within is hardly ever negative.

Posted on

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.

Posted on

ACD Wallboards to Monitor Queues in Real-Time

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.

Posted on

Real-time Agent Skill Reassignment for ACD Queues

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.

Posted on

ACD Call Routing: What Happens When an Agent Misses The Call?

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.

Posted on

Priority Skills in ACD Systems

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.

Posted on

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.

Posted on

Integrating External Applications with Call Center Systems

When a Call Center System is mentioned what comes to mind often is a call floor with many agents dedicated to taking or making calls for a given campaign.  But now more often the case is an office which needed a queue with enhanced features while integrating with their current work flow and applications.  For one example lets take a quick look at how we use the Q-Suite with Redmine in-house with our support department in our unified communications configuration.  The support department’s role is to handle requests from clients coming in from various sources, we get these requests in three main ways:

  • Incoming calls.  Incoming calls have their caller id looked up and are then linked with given project in redmine.  This allows the Q-Suite screens to pre fill out a search and show most recent issues for that given client.  Having this information available helps our support personnel quickly respond to any questions on outstanding tickets by knowing what outstanding items are still open and their current status.
  • Redmine tickets.  Requests with clients entering a ticket directly with redmine or providing feedback on an existing ticket.  The people on support belong to the redmine queue for the clients they are involved with.  Any open tickets are queued and given out to a support person when they are ready for the next while a caller is not queued.  This works well as there are many times during the day when there are no incoming calls and the system delivers the next redmine ticket to be worked on.  This ensures any outstanding redmine tickets are dealt with and not forgotten, something which can be mistakenly done without a system in place.
  • Email. We also have support email which clients use to initiate a request.  This functions very similar except a lookup is done based on the email address and matched with a client.  This allows the person handling the communication to have the same features when a phone call is coming in where they can match it to any open redmine tickets or create a new one as required.

More information on the Q-Suite is at www.Q-Suite.com and Redmine can be found at www.redmine.org