Tuesday, August 25, 2015

Four Keys to Getting Accurate Dispositions

Some agents are meticulous about choosing the right disposition code for a call. Some aren't so choosy, and will click the first thing that lets them finish the call. Assuming you have a way to train those latter agents, you do want to make it easier for the former agents to pick the right disposition without having to spend too much time focussing on the options.

1) The first key to ensuring agents press the right button is to make sure that the labels are clear. As we've discussed before, it's asking for trouble if your agents don't understand what the label is supposed to mean. Sometimes dispositions like HHD5 and R49B can make sense. Other times, they're really confusing to agents. Spend a few minutes thinking about it. Using a few extra characters can make a big difference if it means agents get it right.

2) The second key is to make sure the buttons stand out from each other. If half of your dispositions begin with the word "Call", maybe remove it if the disposition still makes sense. Scanning down a list of options that all start with the first four characters is going to slow the agent down as they spend time reading all the buttons.

3) The third key is button placement. Look at where your buttons are placed in relation to where the agent is working on the screen. You don't want your options such as "Sale" or "Do Not Call" in what may be a default position. Placing the dispositions in the script itself, where you can incorporate them into the agent's workflow directly, may be the best option.

4) Finally, if you're still having issues with the wrong dispositions being pressed, you can always throw a button in there that should not be pressed. History shows that in some cases, labelling a button "Do Not Press" will still generate button presses. You can then follow up with agents to find out why they thought it was necessary to press it. Maybe you missed a disposition. Maybe the agent doesn't understand how their case is actually handled by another button they could have chosen. Getting the button up and following up may be the best way to find out.

Tuesday, August 18, 2015

Agent Desktop Showdown

It's been a few weeks since Windows 10 was unleashed on the world. So far there doesn't seem to be a clear consensus whether it's a must-have or not. Whatever the case, it's got people thinking Microsoft again. Since we talked about agent desktops last week, it seems like a good time to continue the discussion in regards to operating systems.

Today, we'll be discussing two contenders in general terms: Windows and Linux. For Linux, I'll assume a desktop-oriented distribution such as Ubuntu. In terms of Windows, really any recent version can be considered (Windows 7 and up).

Of course, cost can be part of the discussion. Often times, the OS is built into the price of the system, so there may not be a discount for going with a free OS. Even if not, the additional cost of supporting a different system may outweigh the additional cost. Just keep that in mind. If all else were equal, you should be able to equip a desktop with a free Linux desktop OS for less money.

Linux Desktops

There are a few arguments in favour of Linux desktops, and a few against. Let's start with the pro case:

  1. Cost. We've already touched on this, but Linux desktop systems are usually free. You can purchase support for some distributions, but something like Ubuntu is both widely used and free to install/use/update. I've been using free Linux/Unix desktop software for almost two decades. The free part isn't going away due to the way the software itself is licensed.
  2. Usability. Some people are surprised at how usable Linux desktops are. Yes, back in the early days you had to do some crazy stuff to get things to work, but the same held true of Windows as well. From the agent perspective, you need a browser and possibly a softphone to get working. Linux supports the two leading browsers, Firefox and Chrome.
  3. Easier upgrade path. If you want to keep your software up to date, or even upgrade to the next revision, it's simple to do in Linux. On Ubuntu, for instance, you can script your updates, or have it automatically update, or log in remotely and do it. If you're using Long Term Support versions, then shortly after a new one is released, you'll have the option of upgrading via a provided upgrade tool. 
  4. Agents will be less familiar with the back end. Odds are that any software your agents try to load onto the desktop will be Windows-based. Unless you've installed a windows emulator, it won't run under Windows. There are also fewer viruses and attack vectors for Linux desktops.
  5. Easy admin access. Linux was built for servers, so there are several options for administering systems remotely. The desktop is no different. While screen sharing software can be used, just like on Windows, having the ability to use a secure shell to log in and make changes while the agent is working can be useful. 
  6. Quick install. I know Windows installation has gotten better in the last decade, but with Linux you can use network boot, or even install the software remotely. Using the CD/DVD method, you can install and have a fully updated system running in less than an hour. I usually spend several hours running Windows update and rebooting for various settings with Windows. Not so with Linux.

Now to the downsides:

  1. Fewer options for softphones. Several popular softphones such as Bria and Zoiper support Linux. A lot of them don't, though, so you are restricted in your choices.
  2. Lack of familiarity. If you're primarily a Windows shop and don't have a lot of experience with Linux, it's probably not worth installing 100 agent machines that you won't be able to support.

Windows Desktops

The pros:

  1. There are a larger number of software options. There are more softphones. There are more options for productivity software. You can get software from a wider source.
  2. Better hardware support? I'm putting a question mark there, because for new hardware, Windows may be better. For older hardware, drivers may not be available but may be for Linux. There's a scanner here in the office that only works on Linux desktops now, because nobody has a version of Windows old enough to use the supplied (or Windows) drivers. However, manufacturers put the emphasis on working with Windows first.
  3. Familiarity. A near-monopoly on desktop operating systems for nearly three decades mean that a lot of people know how to use Windows.

The cons:

  1. Cost. Windows is proprietary, paid for software. 
  2. Malware. Unpatched Windows desktops are highly sought after and quickly targeted by hacking rings and viruses. Your agents can more easily introduce a virus to your network on Windows due to the sheer number of attack vectors.
The Winner

You. Isn't it great you have these options?

Ultimately the choice is up to you. Of course. But if you've never considered the Linux desktop as an option for your agent systems, you really should.



Tuesday, August 11, 2015

Spec Out Your Infrastructure Properly

Sometimes you see businesses overspend for one part of their infrastructure, leaving the rest to suffer. Sometimes the importance of a particular component isn't recognized until it's too late. We've seen it happen over and over again. I'm here today to tell you that your agent desktops are important. Scrimping too much there can leave your agents waiting around and inefficient.

Agents are usually only expected to use their desktop for accessing the agent screens (via their browser) and possibly a softphone. How much computing power could that need? Well, you may be thinking of clicking around on a single web page or two. Your agent client interaction script may be big and complex, with lots of conditions. Maybe some web services. That's done in Javascript, and Javascript is handled by your browser. Your call center software even has to include checks to avoid double clicks and misclicks because your agents can already click faster than your browser can process things. That starts to add up, both on CPU power and memory.

The soft phone is an additional burden on the system. Handling the audio from your agent, mixing it properly and sending it where it needs to go, and other processing takes resources from the system. If the agent's computer is too sluggish, your clients may notice distortion in the audio. That is not the sort of face you want to present to your clients.

OK, so you can handle the agent screens and the phones. Is that it?

No.

What about any CRM systems you have to interact with? Will your agents have dozens of orphaned browser tabs hanging around in the background, leeching resources? Got those handled? Good. YouTube videos? Spotify? Other services that your agents will probably access?

One last contender for resource hog is the antivirus software you're going to deploy on each of the desktops. That is not only resource intensive when it runs, but it's snoopy. Your antivirus checker is probably checking most of your acivity as it's happening, which can slow things down. You can't go without those safeguards as you can't tell what an obnoxious user is going to try to put on your network, but a lot of people don't count them when they're estimating the specifications needed.

So remember, do your best to try out an agent system or two with a day's worth of load on it: open tabs, agent script, CRM, a video or two playing, and your antivirus software running in the background. That will let you know what your agent experience is like, and allow you to make sure you're buying what they need, not what you hope they'll need.

Tuesday, August 4, 2015

Building A Scalable Contact Center ACD on Asterisk

When Asterisk came along, it was exactly the sort of thing many were looking for. Telephony had been the purview of the giants like Mitel and Nortel. If you wanted a telephone system, you had to pay a lot for a fixed set of functionality. Asterisk gave similar functionality on commodity hardware and much cheaper telephony hardware developed by Digium.

Indosoft had developed against Windows drivers and the Pika cards that were available at the time. Discovering that Asterisk could provide the telephony side allowed Indosoft to adding features and serving clients needs rather than trying to make the phones ring. For the most part it was good. However, we did learn early on that we would be better off allowing Asterisk to handle the phones, but to take more of the responsibility for logic into the Q-Suite itself.

This realization first dawned when we were trying to incorporate the queue priority functionality that was built into Asterisk queues. We configured it as designed, we tested it, and found very quickly that Asterisk frequently crashed when deciding between two queues. It appeared that the feature had been a little rushed, or buggy, and wasn't actually resolved for several months. It turned out to be easier to build our own implementation of queues. Later, we were able to add features that Asterisk queues did not have because we were already implementing the queue logic in the Q-Suite. When we began implementing multiple-server Asterisk contact center ACD, the fact that the Q-Suite was managing its own queues made it easy to spread the concept of the queue across multiple servers. Ultimately the queue functionality in Asterisk was fixed, and Q-Suite also allows those queues to be used as well.

Conferencing is another feature that has long been available in Asterisk. Some dialers use Asterisk to bridge agents and callers. Q-Suite does not do that. However, it does use the MeetMe conferencing application to bridge together three or more callers, when necessary. Originally, if a third participant had to join the call, a MeetMe conference would be constructed, and the agent, client and third party would be connected to it. The MeetMe would only end once the transfer was done, even after the agent had dropped out.

This was an effective approach to transfers, but Asterisk again presented an obstacle: MeetMe conferences are bound to a single core on the system. Back when it was first created, this solved some problems in regards to timing and audio mixing. There were usually only one or two cores on servers anyway. As the years went on, this limitation began to impact the sort of performance you could get from a single server. If CPU intensive transcoding was occurring (such as using G729 codec), you might notice audible degradation after a dozen participants. Each MeetMe conference was using the same core.

Unfortunately, the success of MeetMe on the Asterisk platform meant that there were few candidates for replacement. In Asterisk 1.8, the ConfBridge application did not provide the AMI or CLI interface that MeetMe did. It could not pass DTMF through. And, it had the unfortunate side effect of crashing Asterisk frequently. It clearly wasn't an option for replacing MeetMe.

Again, more logic was put into Q-Suite. It can keep track of participants, decide which MeetMes are no longer necessary, and bridge the two call participants back together, then end the MeetMe they were using. This keeps the number of MeetMe conferences to an absolute minimum. Even call centers that do a lot of transfers generally don't have a large volume of calls where all three participants in a transfer are bridged together.

Finally, as MeetMe conferences are usually bound to a single core, conferences are usually limited to a single Asterisk server. This becomes a problem with load balancing. Of course, Q-Suite manages things so MeetMes on multiple servers can interact as the same MeetMe, allowing scalable conferences transparently to end users.

Tuesday, July 28, 2015

Getting it Right When Some Get it Wrong

There's a fast-service restaurant near my house that specializes in frozen dairy products. Let's say it rhymes with Fairy Shmeen. My order is usually something fairly simple. The drive-thru experience is usually pretty quick and painless. Sometimes, however, there's a problem, and I have to repeat my order several times. Sometimes I have to repeat it after I've gotten to the window. Each time there's a problem, it's the same girl taking my order. I'm sure she's an excellent employee. Maybe seniority dictates that she should have the headset. But she can't seem to get the hang of it. At least not in my case.

In the last decade, there's been a move to remote order taking at drive-tru restaurants. A call center handles all the orders for a number of restaurants. Rather than multitasking employees taking orders while they're blending shakes and making sundaes, the agent taking the order is focussed on that one thing. There's not a lot of wrapup needed for this task, just accuracy and speed. The faster the agent can process the orders, the more orders the call center can handle, and the more money the restaurants can make.

In many senses, the call center is the new factory floor. It's knowledge work rather than manual labour, but the concept is the same. Agents can specialize in certain tasks, and through specialization, efficiencies are realized. Efficiency translates to additional profit for someone in the chain. By collecting similar agents in one place rather than scattering them around the country, things like training and management are greatly simplified. What Henry Ford did with the assembly line is being replicated at workstations in communication centers.

Voice communication, like restaurant orders, are an obvious addition to the call center, when voice has historically been the point. Drive-thru orders aren't exactly like regular calls, though, even though they may seem similar to the agent. Call center software that can handle alternative media like this can also handle things like email queues, social media, and text chat in the same manner. Requests get queued, handled by the correctly skilled agents, and the client benefits. By streamlining this way, everyone benefits.

When you're handling non-call media in a streamlined way, reporting, quality assurance, and adherence to metrics all become easier. In the future, it may even lead to me getting my caramel shake reliably.

Tuesday, July 21, 2015

Managing Do Not Call Lists

Sometimes part of customer service is making sure that you never bother them again. It's a sad part of the call center business, but that doesn't make it any less true. Since the United States Federal Trade Commission established the National Do Not Call (DNC) Registry in 2003, DNC blocking earned extra importance.

In most call centers, there are two kinds of Do Not Call lists:

1) An external DNC list. This may be provided by a regulatory agency, such as the US FTC. It may be provided by an external source, mandated by your contracts. Or you may simply have a means of collecting numbers and putting them on your list. These are people who have not necessarily been in contact with your call center specifically, but that you should definitely not call.

2) An internal DNC list. These are most often people who have requested to be put on your DNC list. This may have been after you made an outbound call, or they may have called for the purpose of being put on your DNC list. Normally, compliance with such requests is mandatory.

Where it gets complicated is there are often exceptions to these lists. For instance, if someone is on a National DNC, but they have specifically contacted you or the company you represent, you may be in a business relationship that trumps the DNC status and allows you to dial. Or your call center may be dialing for an exempt institution. Regulations vary on this from jurisdiction to jurisdiction. In any case, you may find yourself having to maintain different lists for different purposes.

Good call center software will allow you to maintain separate DNC lists per outbound campaign. You should also have the tools to copy lists, load in new numbers from time to time, and possibly most importantly, automatically put anybody on the list when the call is dispositioned as DNC for that campaign.

In addition to the lists, your dialer should check the list at time of dial, so that new additions that may occur after your lead list was scrubbed (you are scrubbing your leads, aren't you?) won't get accidentally dialed and incur the wrath of call recipients (and potential fines). Only with such a multi-pronged approach can you be certain your dialer is not going to land you in hot water.

Tuesday, July 14, 2015

Putting Your Web Service to the Test

As you can guess from recent topics, web services have been a hot issue around here. Whether it's in the dialplan or the agent scripting, we find that call centers are increasingly looking for live data delivered in real time, and web services are a great way to do this.

Where things do sometimes falter is on initial setup and testing. Hours and hours get spent diagnosing whether an issue is on the remote side or in the way the receiver is interpreting the data. Tests get set up and run, the results are checked, then some incremental change is made and the test run again.

It really doesn't have to be that complicated.

There are a couple of tools that we use to help cut down the testing and verification time:

1) Just create a file and have it downloaded. 

If you're sending a request and expecting an XML or JSON file with certain fields back, just create a simple valid case in the form of a file. Break out your favourite text editor and write it out.  It could be something as simple as:


<response>
    <field_1>123</field_1>
    <field_2>ABC</field_2>
</response>
  

Save the file as whatever the response is supposed to be (ie. response.xml). If you have a web server handy (if not, what are you serving the response from?), just place the file somewhere convenient, and have your "web service" return the file. Sometimes you may even be able to encode the URL with the form file:///my-file-path/response.xml and have it read the file in as a web service response. If there's an error, you either created the file incorrectly (which you can check) or your script isn't parsing the response correctly.

2) Try hitting the web service with your browser.

 You may be able to request a response from the web service, at least on a trial basis, by hitting the right URL in the browser window. It may look odd, but can tell you if you're getting the response you expected:

You can also use command-line tools like wget if you need to set specific cookies or can only POST requests.

In either case, you may not be able to resolve your problems with your web services right away, but it should make it much clearer where any issues or unexpected behaviour could lie.