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.
Asterisk High Availability (HA) solutions, once reserved for mission critical deployments, are now commonplace in normal contact center setup. With VoIP, clustering solutions make it relatively straightforward to move IP traffic. Setting up a main and standby Asterisk system will allow such an arrangement to ensure continuous availability of an Asterisk system. Since telephony systems are not mere data systems using IP traffic, such arrangements to ensure immediate availability of the system is inadequate in ensuring the continuation of the calls that were underway when a hardware or software failure happened. Voice solutions require better options. One such option is the call survival capable high availability for Asterisk systems based on US Patent US 20110310773 A1 – a method and system for fail-safe call survival.
One of the most exciting technology to shake the telecommunications landscape in the last decade is Asterisk. Its use in unified communications (UC) and contact centers is unparalleled. Therefore high availability solutions for Asterisk have gained significant attention. The high availability implemented using the above mentioned patent provides the technology to recover calls and successfully continue the on-going calls and conversations in the event of a failure. This technology is available as a part of a call center ACD that manages and scales to multiple Asterisk servers in a cluster to handle very large call volumes.
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.
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.
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
In setting up an ACD System you need an IVR or auto-attendant to get your callers into the queues to be distributed to your agents. However there are a few common pitfalls you can mistakenly get into when doing so.
- Endless loops. A lot of solutions have a built in option to protect a single menu. This is usually done with a max repeat and then a default option. This works for that specific menu but you still need to be concerned an overall loop is not put in place. For example if two menus default options point at each other they can just loop forever without input. I’ve seen a few cases where someone’s phone isn’t properly hung up or the discon from the telco is lost keeping the channel open. The issue is that with a loop a channel of the trunk is busy until that call is cleared. The best way to avoid this is an overall counter to protected against overall loops. This has to be balanced so a normal caller is not affected but users who mistakenly or purposely use up resources can be cleaned in timely manner. Solve this by visually looking at the IVR and all options and put a counter to stop this. It will save on resources by freeing trunks not being used by real clients.
- No pause in logic. I’ve seen a loop configured where it checks if agents are logged in and ready to take a call to a given queue and if not then check another and looping until one if found. This is very much related to the first item if the loop is the dialplan is checking time of day or agents in a queue and not pausing. A pause can be as simple as an audio playback. Without that or a wait, for input or just a delay, the channel will loop and do the checks in the dialplan as fast as the server will allow eating up CPU time and raising the load. If a few callers get into this type of looping it can affect performance of the system which may adversely affect real clients. This example is flawed in other ways as properly configured queues, priority, skills, and time of day rules should avoid the need for this type of check in most cases — but I did see this one configured and almost put into production.
- Inconsistent sounding recordings. This is not going to cause any performance issues but can affect client’s perception and confidence in your business. If the prompts are inconsistent in volume or cut/merged from many small files it will not always sound natural and can be distracting. Solve this by using a professional, for asterisk systems you can hire Allison Smith to record extra prompts or company names needed. If recording your own prompts ensure they are all recorded in a similar manner and normalize the volume if needed.
All of these can be easily avoided with the Q-Suite platform with it’s advanced dialplan builder and audio file management interfaces. Also highly recommended is testing your IVR configuration from time to time to ensure it still fits your needs and functions as expected.