Returning for 2015, What was missed during the holidays.

As the new year rolls in and we start to get back into the normal work day lets review a few posts that might have been missed.

Stephen over on indosftnotes.blogpost.ca continues with Part 3 of How to Populate Client Info which is timely and I can envision uses with open data that James talked on blog.indosoft.com.

Planning an upgrade or new system in 2015? These posts covering pros and cons of On-Premise or Cloud Solutions for your Contact Center may help with your decision.  Both options have their benefits even for those who want to get under the hood although going with a shared cloud solution will limit some options for how deep one can dig.

We’ll be back to the normal weekly posts starting next week.

Decision 2015: On-Premise Call Center?

The old gatekeepers are stumbling. The momentum behind the change to the Cloud has caught them off-guard. That’s not to say that the Cloud is the right solution to every problem, but it is increasingly a solution for call centers that must decide how to allocate their resources in the future. Having said that, decision-makers must weight the advantages and disadvantages of Cloud-based contact centers and on-premise solutions. Continue reading “Decision 2015: On-Premise Call Center?”

Populating Client Information – Part 3: Getting the Data Back Out

Data that can’t be extracted or reported is worth less than data that can be reported. In “Populating Client Information to Agents In Your ACD” Part 1 and Part 2 discussed getting data into the system and to agents. Once the agent has gotten their hands on it, there can be updates, changes or even new data that needs to be reported back. Details about the call usually also falls under the rubric of exportable/reportable data.
Continue reading “Populating Client Information – Part 3: Getting the Data Back Out”

Distinct Agent Logins in Multi-Tenant Call Centers

Not even the clown is me

There is more than one person named Stephen Ray. There are even more people who have Stephen and Ray as part of their name. It’s not the most common name; I’m sure there are a lot more John Smiths, Maria Silvas, etc.. Large call centers often have to contend with name clashes when designating login names for various services, especially when you consider a few years of normal employee turnover. The problem compounds when you are using multi-tenant call center software. Continue reading “Distinct Agent Logins in Multi-Tenant Call Centers”

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.