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 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

Features and trends dictating Multi-tenant Cloud services using Asterisk telephony

The global forecast of the Unified Communications market as a service is astounding. Predominant delivery of this service will be through Cloud based installations offering managed multi-tenant PBX and contact center ACD functionality. Asterisk PBX, the world’s leading  telephony engine, is  a complete platform for communications  that can fulfill the role of a soft-switch, a protocol gateway, a media server, and a VoIP gateway. With a world-wide following, it exercises considerable influence over the trends in the multi-tenant Cloud offering of PBX and call center services.

From its humble beginning as a hybrid PBX, it has risen to a position of consequence with serious implications for the legacy technology platforms. By virtue of being one of the most powerful telephony platforms with an extensive ecosystem, Asterisk offers functionality unmatched by most of its PBX peers.

Cloud based multi-tenant platforms for Asterisk can scale to multiple Asterisk servers with an external ACD, taking effective control of the switching through the Asterisk Manager Interface (AMI) available for individual servers. Powerful multi-tenant contact center ACD software for Asterisk work in a similar way.

The work-flow requirements for Unified Communications is a blend of inbound, outbound and PBX functionality. The PBX functionality includes everything from auto-attendant, find-me-follow-me, to advanced call routing on an individual basis. Organization require conferencing capabilities, email to voice-mail functions and a host of features like virtual cloud extensions, call accounting, ring groups, and ACD (Automatic Call Distribution) from the PBX.

Inbound call center ACD features include queues driven by skills based routing, powerful IVR, call routing, and call distribution. Queues have skills association and calls are routed to the appropriate staff available at the time. The ACD provides powerful real-time stats. Outbound workflow has changed dramatically in the last decade. From mass dialing, it has become selective dialing driven by effective CRM. The integration to CRM packages like Salesforce, Netsuite and Microsoft Dynamics provide visibility into the life cycle of leads.

Most Cloud multi-tenant PBX installation achieve greater marketability by offering call center functionality along with the PBX. A multi-tenant contact center software will be incomplete without offering full function PBX. The user-interface of a good Unified Communications system should blend inbound, outbound and PBX functions.