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

The Rapid IVR Development Tool for Call Center ACD

The ability to create and deploy an Interactive Voice Response (IVR) is a must for modern contact centers. An IVR handles the voice or keypad response of a caller. One rapid IVR development tool is a visual dialplan builder that allows the building of a sophisticated IVR using graphical icons representing the extensive IVR functionality required for a contact center ACD, within a drag and drop framework. A good Visual IVR builder tool can allow one to fulfill even the most demanding call flow requirements with ease and precision. Continue reading “The Rapid IVR Development Tool for Call Center ACD”

Posted on

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.
Posted on

Multi-channel ACD in a Cloud setup

Cloud is the new frontier for voice telephony and the contact center ACD (Automatic Call Distribution). The convergence of the transport mechanism for Voice with Data through Internet Protocol (IP), the acceptance of Session Initiation Protocol (SIP) as the default standard for Voice over IP (VoIP) transmission, and the consolidation of infrastructure accessible through Internet, have created a favorable environment for the growth of ‘Cloud’ based contact services.

Depending on the size and scale of a contact center operation, there are some options on how best to migrate to the Cloud. The larger operations can move to managed services in a Cloud platform where they exercise control over the operation without actually owning all the infrastructure. The smaller operations can be a part of a multi-tenant installation that is segmented and partitioned to provide an exclusive setup. Both these options provide a number of advantages including lower cost of setup and operation as well as the ability to have a geographic distributed work-force.

A multi-channel ACD handles more than voice. The additional channels may handle Chat. Email, and Social media. The ACD serves to distribute the conversations based on skills based routing but the media in the individual channels are handled by the respective media server. In the case of voice communications, the media server is the PBX switch. Asterisk dominates this category as a hybrid PBX which works seamlessly with both VoIP and the traditional Time Division Multiplexing (TDM).

The underlying technology stack for setting up multi-channel contact center ACD does not differ very much between a premise installation or a data center installation in the Cloud. With a competent hosted service provider to offer managed services, this can dramatically reduce the associated Information Technology (IT) operational cost. Also, sites with good connectivity offer the ability to have geographically distributed and remote agents. Some contact center software are multi-tenant by design and this enables the hosted service provider to offer shared IT resources for its tenants, thereby lowering the overall operational cost.

Posted on

Cloud is in ‘vogue’ now but Cloud contact center services have been around for a long time

Folks at Indosoft remember deploying a distributed contact center platform for one of our customers at a co-lo in Chicago sometime in 2006. Their agents were working from South America and different locations within United States.  They had looked us up on the web while reviewing Asterisk related technologies. Asterisk had by then made quite an impression with its flexibility and feature-sets supporting both VoIP and TDM.  Back then, PRI was the preferred telecom termination and SIP with X-lite for agent telephone was a workable option, the big challenge being bandwidth. Continue reading “Cloud is in ‘vogue’ now but Cloud contact center services have been around for a long time”

Posted on

ACD for Business Verticals migrating to Asterisk

Telecom is going through a paradigm shift with VoIP dictating the direction. This has profound impact on business verticals where voice communication is a critical sub-set of their overall system. For example, sales and service departments, dealerships and similar functional units use custom applications and ERP systems which co-exist with good telephony platform. There are also other custom applications built to manage unique processes that require CTI functionality to handle voice communications. As these domains move forward with next generation systems for their business verticals they will require a next generation telephony platform with VoIP capabilities. Continue reading “ACD for Business Verticals migrating to Asterisk”