Monday, November 24, 2014

Populating Client Information to Agents in Your ACD - Part 2

In Populating Client Information to Agents in Your ACD - Part 1 I talked about getting your client data into your call center ACD software. That's an important step, but it doesn't complete the task. Today I want to address the topic of finding the particular contact who is calling in and presenting that information to the call center agent.

Identifying Callers

There are a few ways the caller can be identified. Building a dialplan through a call flow builder allows an opportunity to do matching via the caller ID or by data entered by the user. Additional information may be consulted to assist with identification, such as the DID the client called in on. Other methods will require agent intervention.

Caller ID Match in Dialplan

A good IVR builder should allow you to match or branch on available data such as the caller ID. Not every call will present a valid caller ID due to technological, jurisdictional and privacy considerations. The number of calls that do come in with a valid caller ID make it a good, solid starting point for determining the identity of the caller. If you don't have duplicate phone numbers in your lists, and you can determine which list of contacts to match against based on the dialed DID, it should be a simple matter to match a contact based on the phone number and send that along as part of the call information. In cases where no match is found, or the caller ID was unidentifiable, you can branch to a section of dialplan that collects more information, or pass it to the agent as-is for matching on the agent side.

Getting an Identifier in the IVR

A match may not be possible based on caller ID. In that case, your IVR builder can be used to generate a bit of data collection. Using uploaded audio prompts, you can indicate which data you wish the caller to input, and use the dialplan functionality to read the supplied information. An account number might be requested, or even just the phone number that the client is calling in on if you're typically doing caller ID matching. Once the data has been collected, a match can be checked for again.

It should be noted that whether the caller ID is being used or other data collected in the dialplan builder, the matching can be done internally for locally-stored contacts, or via a web service when the data is held by a third party. The Q-Suite allows web service calls with any field that is available in the IVR at the time of the call to the service. This can include data entered in the IVR by the client.

Letting the Agent do the Search

If the call reaches the agent without the client having been identified, then the agent will have to do the work of identifying the lead. Ideally, the agent should have a client interaction script with search capabilities. Having the client on the other end should allow the agent to query certain fields to uniquely identify a client. Sometimes it will be necessary to add additional fields and try again, but the agent is in the best position to determine who is on the other end of the line. Even if the search returns multiple contacts, the agent should be able to determine the correct one with just a few questions.

If it turns out that the client is not currently in the system, the agent screen is where it makes the most sense to create the new contact. This does take additional time, but a properly worded script should allow the agent to collect the required information in the most efficient manner, allowing the agent to get on with the actual purpose of the call.

Once the agent is handling the call, it's important to make sure the contact information is up-to-date, especially for data that can change more frequently. By ensuring the currency of contact data, you can provide the best customer interaction possible.

Wednesday, November 19, 2014

Connecting Call Center Agents

It looks like there's a common theme running through recent blog posts. At the Indosoft blog this week, I wrote "Remote Agents in the Modern Call Center" discussing connecting at-home and remote groups of agents to a call center.  This seems like an obvious expansion of the Cloud to call center concept.

I had originally considered talking about connection methods in my post, but at the last moment cut it out as not being as important. That is a topic that was covered last Friday by Shaun, who wrote "Connecting Agents to the Call Center ACD" which talks about the types of devices an agent can use to connect in.

A couple of weeks ago, Brian wrote "Agent Connections With an ACD System" which discussed on-hook and off-hook agent connections, as well as VoIP vs. dial in or dial out connections for agent phones.  Between all three posts, I believe the topic of connecting agents to a call center is pretty well covered.

Monday, November 17, 2014

Populating Client Information to Agents in Your ACD - Part 1

One of the major purposes of many inbound call centers is customer care.  Clients may call with technical issues, be updating their orders, or enquiring about new services. In this case, it's obviously important to ensure that the agent handling the call have as much information as possible about the caller. The question becomes how do you get those details into your call center software and in front of agents?

Accessing External Data

The most expedient answer is often incorporating an external database connection or call a web service to populate information in the agent script. A good agent script builder should allow access to external data sources. Often we are relying on a third party for client information, and it can be simpler to access a web service, database or API to pull information live on an as-needed basis. In some cases this may be the only option available, especially if data may be updated outside the call center software, ie. by another call center or data service. This method does have some downsides, though. It requires the center to have a fast connection to the data provider. Any slowdown in that connection impacts the ability of agents to do their work. Also reporting may be impacted, as the call center data and provider data aren't necessarily in sync without some work.

Keeping Data Internally

Keeping the data internally is the obvious alternative to accessing it externally. Having it available in a database directly connected to your call center software allows simpler integration and use of the data. It also avoids synchronization problems and potential issues with connectivity. If you are to take this approach, there are a few ways data can be loaded into the software:

  • Preloading bulk contacts into a list
  • Incremental imports of small groups or single leads
  • Updates of existing contacts via API or administrative functions
  • Contact creation/updates via script when client calls

Preloading Bulk Contacts Into a List

A good call center software suite must provide a method of importing contacts into lists which can be assigned to groups of inbound phone numbers, sometimes referred to as campaigns, or individual call queues. Each campaign may need to have a different set of contacts; ie. customer care may have access to a global list, while an individual product group may be limited to clients of that particular product.

In the Indosoft Q-Suite, templates and a contact loading admin screen allow for the bulk importation of contacts in CSV or Microsoft Excel formats. These are widely supported, making it simple to receive contacts from the source and upload them into the system.

Incremental Imports of Small Groups or Single Leads

Often contacts are inserted when a new client makes a purchase, or a prospect fills out fields in a web form. Using APIs, it's quite straightforward to go from web prospect or purchase to inserting a contact into the call center ACD database.  A third party can also easily upload small sets of leads via API without requiring full access to the software. This allows quick integration between sales, prospects, and your customer care team.

Contact Creation/Updates Via Script When Client Calls

This one is pretty obvious, but for some call centers this can be a primary source of contact information. If a clients first contact with your company is through your toll-free number, contact creation will happen when your agent collects their information. It's important to have a good client interaction script to ensure that the correct data is properly collected. You should also make sure that your script prompts the agent for any updated information when a client calls in.

Updates of Existing Contacts Via API or Administrative Functions

The same methods you use to import contacts should also allow for updating of contacts. Good call center software will give the option of updating a lead if it exists, inserting it if it does not.  In Q-Suite, this is available as a flag when creating your template.  This gives you the flexibility to allow updates where needed, and prevent them in cases where the contact data must remain unchanged. Having the API available allows third party providers to update the leads without requiring your intervention.

Now You Can Decide

Ensuring your agents have contact information at their fingertips at the time of a client  call is an important factor in a positive outcome for the client.  It is therefore important to consider both the source of the contact information, any contractual obligations and restrictions, and infrastructure limitations to determine how this should be provided. You can then choose a call center ACD software that allows you to manage your data the way you choose to.

Thursday, November 13, 2014

Rapid Reconfiguration of Servers For Cloud-Based Call Centers

Hosting your call center software in the Cloud, as regular readers of this blog know, allows for a flexibility in the allocation of resources that is simply not available in on-premise call centers. In a large call center deployment, a number of servers are usually provisioned for specialization: web servers, database, telephony, etc.. Changing conditions can mandate that the mix of servers should change over time. In these circumstances, it is important to have the ability to quickly repurpose a server.

As an example, Q-Suite 5.7 moved the server software options from config files and the installation process to a web screen and background script. This allows a system administrator to add or remove server types such as "Web Server" or "Asterisk" from each server. Once the appropriate settings are made, a background script can be run to make the changes live. The whole process can be done in less than a minute.

The advantages of the Cloud include flexibility and on-demand availability. Don't handcuff yourself by choosing software that doesn't extend those benefits.

Monday, November 10, 2014

Trunk Selection and Cost Control - Simple Least Cost Routing

A priority for any new call center installation, once calls are being successfully dialed, is making those calls at the lowest cost.  Trunk usage charges are a very visible number, and a tempting target for savings.  It is vital that call center software offer a means of ensuring that calls get dialed in an economical manner.  An Asterisk Cloud-based call center should be no different.

Least Cost Routing solutions can be very complex, and it's easy to get lost in the technology.  However, for most call centers, the needs are very simple.  Trunk providers don't often expose clients to the details of their own costs, and usually simplify the price sheet to avoid confusion.  Therefore, the opportunities for lowering costs are usually quite obvious.  The most common cases encountered are:

  • Local calls (whether local means a city, state, calling code or country) are cheaper with a local provider
  • Non-local calls are cheaper with a larger carrier who does not offer lower-cost local dials
  • Mobile calls may be cheaper with one provider versus landline calls
  • Out of jurisdiction (out of country, overseas) calls are cheaper with another carrier
It's often the case that out-of-country or overseas dials are not done at all, or are done infrequently enough that shopping around for another provider for these calls isn't worthwhile.

In these cases, it's usually straightforward to determine phone number patterns that identify a phone number as belonging to one of the above groups versus another.  Asterisk itself includes pattern-matching, if you're willing to get your hands dirty and edit your config files manually.  Q-Suite 5 has long offered the ability to set trunk routing rules; patterns that identify a number as being ideally routed over one trunk or another.  It is certainly possible to say that a certain dialing campaign or extension should use a specific trunk for all calls.  When there is a large disparity in costs and a number of leads that should be handled differently, however, having the ability to set up least cost routing via the admin interface can be very helpful to the bottom line.

Thursday, November 6, 2014

Cloud Storage in the Call Center

Over at the Indosoft blog I made a post about Cloud storage in the contact center.  Using the Cloud for storage when your call center is already in the Cloud is a no-brainer.  However, we are seeing the adoption of Cloud-based storage for on-premise call centers as a way to get around some of the issues that arise when archive recordings.  Some of the post may be of interest to readers of this blog, so I encourage you to give it a read.

Monday, November 3, 2014

Bringing Instances Up and Down to Improve Performance and Save Money

One of the advantages of deploying a feature rich call center software suite in the Cloud is that there are feature rich APIs and tools available for managing both software and cloud infrastructure.  The APIs of more advanced Cloud providers are of interest where they allow a call center to bring pre-configured instances up and down on demand.  This can result in a significant cost savings when a major factor in the cost of the service is CPU usage.

The ability to load balance servers to expand service capabilities in the contact center is a key attribute in easily managing a call center software deployment.  In the case of an Asterisk based ACD, for instance, calls and agents must be spread out to avoid creating an unnecessary bottleneck.  This has been discussed here very recently, so it's not necessary to belabour this point.  Being able to balance load over a set of servers may allow you to specify the set of servers being used.  If this can be managed in real time, or on a scheduled basis, then it should be possible to move load to or from servers as capacity demands.

This point is especially relevant for call centers.  While web and application traffic may stay at consistent levels in our 24/7 world with all corners of the globe wired in to the Internet, most call centers still have busy and quiet times.  If we know we are likely to only need a third of our capacity for a reasonable length of time (ie midnight to 6am UTC), bringing down a half of our servers should certainly be feasible.  As long as the software allows the system to mark certain servers as unavailable for new calls or agent connections, or mark them as available again, we can be open to bringing servers down.

If the call center software can be configured via API to manage load and server deployment, then the same method can be used to signal the Cloud provider that instances can be brought down and up again.  With a reporting API available, it would even be possible to devise a system to bring capacity up and down automatically.  Cases would have to be devised to cope with any delays that are possible in such a procedure, but could certainly be worked around.