Three Common IVR / Auto-attendant problems

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.

ACD Queue Core Features

This blog is called ‘asterisk acd’ so lets review some core features one would expect with a system providing ACD queues. These features are some of the key functionality that allow ACD queues to improve customer relations and call taker productivity.

  • Queue Priority. Often higher priority queues are requirements for a center. These allow higher priorities callers to be answered sooner than the others but when all things are equal the longest waiting caller is answered. Using a mix priorities with queues requires a well thought out configuration to balance the number of call takers are assigned to which queues as you want to ensure the lower priority queues are still served in a timely manner.
  • Queue Overflow. This can mean a few things. First is once a queue has hit the high water mark for callers waiting in queue any new callers can be directed in the dialplan to avoid an excessive wait. Second, once in the queue if callers wait beyond a time limit they can leave the queue and go to another or elsewhere in the system. The last is to skip the queue if no call takers are currently logged in that would service that queue and continue in the dialplan to either a staffed queue or any action needed.
  • Queue Callback. Allows a caller to keep their position while not waiting on the phone. This is typically a DTMF triggered option that is announced while they wait in the queue and might, and usually should, confirm the number to be called back.
  • Queue Announcements including Position. Allows playing a message to any caller waiting in queue. This can be helpful to announce their position in the queue so they have an idea of how long they will be waiting. I would not include wait time as previous answer times are often not accurate for those currently waiting, it is especially bad if the times announced are past by the caller.
  • Queue Reporting. To manage all of the above and ensure their configuration is working as expected one needs to be able to monitor the state of the queues. This would require a combination of a WallBoard to watch queue status in real time plus a historical report to allow mining data from the past to predict future needs and/or adjustments.

Call Center Software for Cloud Deployment using Asterisk

Asterisk is a versatile VoIP PBX telephony engine that has experienced phenomenal growth from inception. Its market penetration is not easily measurable due to the diversity of applications using it.   It should come as no surprise that Asterisk has a significant presence in Cloud installations as it can function as a telephone switch, a media server, a protocol gateway, and a conference bridge. Asterisk has become a preferred choice for the underlying telephony platform for setting up distributed multi-tenant PBX and call centers.

We are seeing more providers choose Asterisk or telephony platform built around it for their cloud deployments.  For example a recent announcement about VitalVox selecting the Q-Suite platform which uses Asterisk.

Most providers are not going to roll their own Asterisk solutions due to the extensive toolset needed to maintain the dialplan while separating multiple tenants easily.  This is where the value of a product like the Q-Suite comes into play as it handles low level configuration of Multi-Tenant PBX and Contact Center.  Then of course there are Reports which are also included in these products which provide real time and historical system utilization, call stats, etc.

Which Telephony Interface for your Solution: VoIP Gateway VS PCI card?

What is your PBX or CTI solution without an interface to the outside world. One can use VoIP but there are still a lot of systems going the traditional route and connecting to a Telco either via Analog (POTS) or a T1/PRI/E1.  With Asterisk the two main solutions to do this are an internal PCI card or an external Gateway device. Both options will make and receive calls from the telco but which one is better?

I’ll cut to the chase and say PCI cards should not be recommended for High Availability solutions. They can still have their place in a system without HA and where costs are a major factor, but the decision to use them should be made with their limitations in mind.

Using a Gateway device, such as Patton or Audiocodes, provides the following benefits over an internal card:

  • Multiple telephony servers can connect to a single gateway. Which is important for the next two items.
  • With multiple servers connected to a single gateway in a HA solution calls will be routed to the active server(s).
  • Load balancing done at the gateway level in a high volume centers to distributed calls across servers.
  • Independence from a single server. If a specific server needs to be rebooted or taken offline for maintenance a gateway will keep working.
  • Location of telco demarc can be independant of telephony system. This can be in a different room, floor, building or even country. Just be careful of lag causing issues. But given the proper connections can allow moving the IP PBX system into the cloud while still supporting traditional telco trunks.
  • In a mixed trunk environment of VoIP and traditional telco connections the Gateway can abstract this so the IP PBX’s configuration is similar for all trunks.
  • Scaling up only requires adding a new gateway and a configuration change to the telephony system which minimizes downtime and risk.  Mainly due to avoiding the need to open the system to install new cards.

Considering the above it is hard to see the case for a PCI card, especially in an HA solution.  They may still have their place elsewhere but I’ll be recommending a VoIP Gateway going forward.

The Challenge of VoIP System Failures Not Addressed by Most High Availability Designs

Hardware or software can fail at anytime and induce a system failure. It is not possible to reduce such failures to nil. When VoIP based systems experience such failures, it results in the loss of on-going calls. High availability (HA) or redundant systems cannot address this unless they are capable of restoring an on-going call without either one of the end-points re-initiating the call. Most high availability system for Session Initiation Protocol (SIP) based VoIP calls and their redundancy setup, deploy an immediate replacement of the failed component/sub-system to allow continued use of the system. It is good enough for many situations but it might not be adequate for mission critical applications when the HA cannot not restore on-going calls.

Imagine a scenario where an outside caller initiates a call and when it hits the demarcation point of the contact center installation. This could be a premise based contact center or a Cloud set up offering virtual contact center services. When the call setup reaches the intended peer and conversation starts, it is possible that your system, either Cloud based or on-premise solutions, could experience a failure. Once the system detects a failure, its high availability and redundant setup will kick-in and the system will be ready for future calls but what happens to the on-going call? They just die. This is the normal operating mode of traditional high availability systems including most high availability solutions offered for Asterisk. This issue becomes more critical for large contact centers using automatic call distribution (ACD) with significant traffic at any given time.

With contact center ACD, the importance of going beyond the traditional high availability is extremely important. Having the capability to keep calls alive through call survival is critical. This will allow the user to continue the phone conversation without the need for re-initiating the call. It is a sophistication in offering redundancy that goes beyond recognizing the need to bring into action the replacement software and hardware components. It introduces intelligence required in preserving all the on-going calls essential for mission critical systems.

SIP Registration Timeout Settings for High Availability

In setting up a high available telephony system most worry about the back end and ensure it functions as they would expect and require.  However one highly visible user issue I have seen is a misconfiguration of the connected SIP phones in regards to the registration timeouts.  When these are very high on your SIP phone then it may not notice a service has moved (via IP/DNS/etc changes) due to a HA switchover and can potentially miss incoming calls until it does.  Typically an outgoing call attempt will work or at the very least cause a registration attempt to the new server the service has moved to.

For example take a look at Aastra, their defaults in a few models I’ve seen are at a half hour for a failed registration.

aastra-default-configuration-reg-failed-retry

If the failed registration timeout is half an hour and the phone attempts to re-register and fails your phone will show an error or unregistered for the next half hour.  This can happen in the cases where the registration comes in as a box is failing or a failover happened and the configuration is being written/updated due to the switchover process.  More reasonable set of values are shown in the following.

aastra-configuration-reg-failed-retry

In this one I’ve lowered the registration failed retry and also the timeout retry timers.  These will make the SIP phone resolve the registration issue quicker by retrying more often than the defaults.  They could be lower depending on the situation.

One precaution before everyone sets these very low.  These settings should be set appropriately when the SIP phone is off-site and there are protections, for example Fail2Ban, in place to block brute force attacks.  In these cases where the SIP phone is on an app on a mobile device this failed registration timeout should be set high enough to not trigger a lockout of a valid device.  If the devices are in-house or IPs can be whitelisted then the values can be lower without worry.

The Differences in Call Survival and Call Recovery

While investigating High Availability (HA) in CTI and PBX systems you will often find mention of Call Recovery. Another term you run into is Call Survival, which is often used interchangeably with Call Recovery incorrectly. This is because each is a different approach to solving a problem. The problem being a failure which would interrupt the calls of a system.

With Call Survival when a failure happens the caller and callee do not have to take action to continue their call as it survives the failure. At a high level this is done by reacting to the failure quickly and re-routing the audio path around the failure.

With Call Recovery when a failure happens the recovery is different depending on the system. Sometimes the caller will need to initiate the redial the callee or it could be an automated process but the callee still have to answer this new call.

From a user perspective the better option is Call Survival as they may only experience a momentary interruption in their audio as the path is rerouted around the failure instead of having to re-initiate a call to recovery it.

The Q-Suite platform supports Call Survival with the help of the Overseer Watchdog providing HA for other services in addition to being one part of the Call Survival solution.

Web Services API for Asterisk based ACD

The dominance of Asterisk in the hybrid PBX market is unquestionable. So is the use of Asterisk as a primary telephony platform for contact centers around the world. Customer contact operations also require a powerful ACD and Dialer. Larger operations require more automation and standardized method of integration for the administration and management of the contact center software.

Continue reading “Web Services API for Asterisk based ACD”

Next Generation Contact Center Technology Stack

Making informed decisions on the technology stack required to setup customer contact center is very challenging. The overall costs of the proprietary product stack of well known manufacturers like Avaya, Cisco and Aspect are daunting. After all, their internal costs are going up for everything from salaries to marketing and everyone has to sell more or sell for more to keep up with this.

Continue reading “Next Generation Contact Center Technology Stack”

Integrating CRM and ERP Applications To Phone Services

Customer Relationship Management (CRM) software record, unify and manage the business processes. It is usually industry specific and highly evolved. In most cases, there is a close relationship between phone services and CRM. The need to integrate phone services with a CRM or an ERP application is growing and presents an unique opportunity for CRM/ERP vendors to enhance product offering and increase productivity for its end-users. Phone service integration with sophisticated ACD and Dialer features will enhance the usability of the CRM and ERP software. Continue reading “Integrating CRM and ERP Applications To Phone Services”