asterisk Archives - Page 2 of 5 - Contact Center Software for Asterisk Telephony

January 27, 2015

Let It Flow: Customizing Your Call Center Software Part 1- Customizing Your Call Flow

A big driver of the adoption of Asterisk is the flexibility it brings. It has been called the Swiss Army Knife of telephony with good reason. As a result, there are a number of things that one can do to utilize that flexibility and add a bit of customization to their Asterisk-based call center software. In most cases, the actual amount of modification done is pretty small, but it’s always nice to know the ability exists if needed.
Continue reading “Let It Flow: Customizing Your Call Center Software Part 1- Customizing Your Call Flow”

January 23, 2015

Transfer Types in the Call Center ACD

In a previous post, I talked about call transfers in the contact center. I am going to expand on this topic, and am going to discuss the types of transfers that can be done in the Q-Suite. These types are a little different than the other ones and describe a bit more about the destination target of the transfer. Continue reading “Transfer Types in the Call Center ACD”

December 9, 2014

The March of IP Telephony – Part 2

It’s startling to realize how quickly IP telephony did get accepted. Even in 2008, when Rajan posted The March of IP telephony – Part 1, the bulk of our clients were using TDM boards. Digium and Sangoma hardware were our go-to choices. Innovators like those two companies were blowing up the market. This allowed Asterisk to continue to build on its foothold. Clients looking for stability were increasingly able to choose Asterisk, but still connecting via PRI. Selecting a quality VoIP carrier was a difficult process for those not sharing a colocation facility with a reputable provider.
Continue reading “The March of IP Telephony – Part 2”

November 20, 2014

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.

October 28, 2014

Influence of Asterisk on Cloud call center landscape

Cloud based managed service providers are rapidly growing. The most recent financial statements from inContact and Interactive Intelligence point to this trend. Most call center software vendors are making a concerted effort to move from selling hardware and software as a product to selling an on-demand service. This move is being thrust upon them by the rapid change in networking and infrastructure. But the biggest threat to their survival comes from technology companies that leverage Asterisk and other open source elements for the technology stack.

Continue reading “Influence of Asterisk on Cloud call center landscape”

October 17, 2014

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.

September 25, 2014

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.

September 12, 2014

Softphones for Contact Center ACD

In the ever-evolving realm of contact centers, minimizing startup and operating costs should be high on the list of items that a center should want to accomplish. There are numerous way to go about this, such as buying used office chairs instead of new ones, but if you are looking to cut costs without sacrificing functionality, using softphones instead of physical phones can be a good start. Continue reading “Softphones for Contact Center ACD”

September 9, 2014

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.