Friday, April 24, 2015

The Startup Call Center - Be Nimble, Be Quick

"Moving at the speed of business" is a cute slogan, but if you're trying to get your venture off the ground quickly, that may be too slow. You've got dozens of things you're trying to get going at the same time, and you can't wait. Odds are you're using the Cloud for a large part of your infrastructure. Your customer service line shouldn't be any different.

We've talked about the benefits of having your call center hosted in the Cloud before. We've talked about how monthly licensing your ACD (Automatic Call Distributor) can get you the services you need at the price you can afford. Early on, running out of money is a big danger. You can't blow it all on an expensive legacy system, or getting your server room set up. With Cloud call center software, you can have your minimal service level up quickly. If you need to expand suddenly, it's easy to add licences.

Whether you are starting out small, are already huge, or just need to ride out a surge in calls, Cloud call center software can help you manage your needs. Even if you're running a big operation, thinking about your minimum can save you money while leaving you the scope to handle your maximums. If you're starting out, you can be confident that the capacity will be there when you need it.

Wednesday, April 22, 2015

One Way to Stop Overloading Your Telephony Server

There is a subset of your staff doing most of the work. This is the well-known Pareto Principle, where 80% of results are achieved by 20% of causes. 20% of your employees are doing 80% of the work. 20% of your clients are responsible for 80% of your profits. Understanding how this works in your cloud-based call center can help you be more efficient. Having 20% of your telephony servers handling 80% of the calls can be a recipe for disaster.

You may have one number that comes in on one trunk, and use smart IVR routing to get calls to the right spot. That's pretty common. Your SIP provider may only allow one IP to communicate with it. That's also pretty common. If you just point it to the first of many telephony servers, though, that server is going to be doing a lot of work. One strategy is to have agents distributed across multiple servers to spread things out. Another is to have multiple trunks. None of these solutions is ideal for heavy usage cases. On commodity or Cloud hardware, you will reach the capacity of a server, and be stuck. It's worse if you have occasional bursts of activity over one trunk or another.

Load balancing is very important under heavy call volumes. For telephony, this is usually accomplished by having a load-balancing SIP Proxy in front of your telephony servers. Handling the media (voice, usually) is the hard part of a Voice over IP (VoIP) call. Signalling is fairly lightweight. Telling the server a call is coming in, accepting it, saying "Yes, I'm still here" is really just some text being passed back and forth. Taking the audio, encoding it, breaking it into packets and sending it off, possibly recording it, is the hard part.

One interesting fact about most VoIP traffic, such as SIP, is the signalling and media can happen on different servers. In the case where only one server is allowed to connect to the provider, this almost always means the signalling. The media can, and often does, connect to a different server.

On inbound, a SIP proxy handles the easy part. It can also decide which of the available servers will take the next call, and arrange the details between your server and your service provider. This way, there's not one single server in a multi-server call center that's struggling with 80% of the call volume.

For outbound, the usual solution is to have your trunk proxied, and the outbound load distributed evenly. This usually means spreading your agents out so the outbound call volume doesn't overwhelm the server. Again, your SIP proxy looks like the trunk provider to each of the servers using the proxy. The call gets dialed, then the media is processed as normal.

In either case, whether inbound or outbound, you can avoid having the Pareto Principle cause disruption. The better you do with call distribution, the fewer complaints you'll have with call problems.

Thursday, April 16, 2015

Crunch Time is Coming

cloud call center crunch timeCrunch time is coming. You can prepare for it and sail through it, or you can let it overwhelm you and lose the respect of your clients. Some call centers handle crunch time poorly, no matter how far in advance it's known. April 15 comes at the same time each year, after all. So does Christmas, Thanksgiving, Memorial Day weekend, Labour Day, the end of the year.

Having your call center in the Cloud offers real advantages for scaling up quickly for peak calling season. Bringing in additional resources, beefing up the servers you already have, and connecting remote agents in temporary locations are all options. Adding temporary servers in the Cloud is far less trouble than adding additional servers to your server room. Your agents are already logging in from a location separate from the servers. Increasing agent capacity could be as simple as adding an extra training class and renting additional office space for a month or two. Also check for obvious problems with your IVR that hurt the client experience.
Once crunch time is over, you can go back to normal. Bring down the extra servers. Let the temporary space go. And start planning for next year's busy season.

Tuesday, April 14, 2015

One Number, One Big Problem

If you have one public toll free number you advertise broadly, you may have a problem. It's something we've seen several times in the past. Giving the client one number to call solves their problem of deciding which number to call you at. The problem of taking that call and getting it to the right place now becomes yours. If you only ever have one type of call, then you can probably figure it out pretty quickly. Otherwise, you're going to need help from your Interactive Voice Response (IVR) builder.

Your inbound IVR, or dialplan, has to have the intelligence built in to route the call correctly, possibly with user input. Using a dialplan builder, there are two primary ways to do this:

  1. Play the options for your caller and let them choose via a menu
  2. Branch on known data.

Play the options and let them choose

This is the most common IVR type most people are aware of. They hear an audio file, enter a digit at the prompt, and continue through the call flow. This may involve another menu further down the line. An auto attendant is usually enough to provide this functionality. That's not to say that you can't do call pre-processing and already have done some routing.

Here the important aspects are making sure that you have an audible, good quality prompt that clearly lets people know their options. It's also best if you don't present too many options at once. You can always subdivide categories later with another menu.

Branch on known data

This is a bit more complicated. It may look like there's not a lot of known data to branch on. You may have more information than you realize, however. You might also be able to get the client to supply you with more. Things like caller ID and the number they dialed are known right away. You can ask them to enter their postal code (if your jurisdiction has numeric postal codes), or an account number. That can lead you to more information you may already have. Here's an example:

A national brand has an advertising campaign with one toll free number. Everybody interested in their services uses that number. Repeat customers also use that number to call in.

  1. The caller ID is matched against existing client records.
  2. If a client record is matched, its data is associated with the call, and any postal code information is set in the dialplan
  3. If the postal code is not currently known, the client is prompted for it.
  4. An internal database is consulted to check to see who services that postal code. Some postal codes are handled by the company itself, and the others are handled by franchisees.
  5. If the postal code is handled by a franchisee, the call is transferred to the number on record for that franchisee. If the call is not answered within 30 seconds, the call drops into a queue for such calls.
  6. If the postal code is handled by the company, calls can go into one queue for new clients, or if it's repeat business, into another queue for those callers.

In the dialplan builder, we would use a component to associate the call with known contacts, then a branch, then a user prompt, then a simple lookup component, then another branch, then transfer or queue components.

Visual Dialplan builder results
In the example shown, you can see how the call comes in and flows through the dialplan. The postal code is retrieved either in the "Call List Data" component, or the "DTMF" block where we request the data from the caller. We can then look up the postal code in the "Inbound Call Router" which simply pulls a row of data from a lookup table. In this case, it specifies a phone number if it's a franchisee. Once we've collected these items, it's a simple matter of routing the call where it needs to go.

Thursday, April 9, 2015

Don't Fumble The Handoff

a good handoff is keyFew things bother people more than having to repeat information they've already provided. It wastes their time, and they know it's wasting the agent's time, too. So why do call centers let this happen? It's understandable if you're calling into a PBX system and the call recipient can't do a transfer correctly, but it's something that can be avoided in the call center.

With a good Interactive Voice Response (IVR) builder you can collect a lot of information before getting to the agent. Giving your caller options as to the nature of the call as well as data collection for things like an account number should be able to shorten the actual call time. Assuming your call center ACD (Automatic Call Distribution) software is integrated with the dialplan, your agent script should be populated with the information already collected. Then your agent can confirm the information they have, rather than asking for the information again. If it's necessary to not relay this information back for security reasons, let the caller know you're simply verifying the information in front of you. Confirmation is good. Wasting people's time is not.

Sometimes the call is not with the correct agent, however, or it has to be escalated somewhere else. Or maybe the customer has something they want to discuss with another client. It's really frustrating to talk to someone for 10 minutes, then get transferred to somewhere where they have to repeat the conversation. To combat this, call centers should be using warm transfers.

Warm transfers, at the simplest, are transfers where the original agent speaks with the new agent. Sometimes this is done with the customer present, sometimes not. The important part of the warm transfer is that there is a transfer of information from the first agent to the second. A blind transfer does not accomplish this. The agents should make sure that all the information that is needed is being relayed. Once that has been done, the transfer can complete and the first agent drops out. Of course, this requires call center software that allows consultative (only two parties in the call at any time, with the third leg on hold) or conference (all three parties in the call at the same time). 

What could be better? If you're transferring to another agent on the same system, wouldn't it be nice if the information on the first agent's screen made it to the second agent's screen? That way, the second agent could save everyone even more time by verifying he had the information there before continuing on with the call. Modern call center software is capable of letting the first agent save the data and bringing that up on the agent's screen. After all, that's what the caller assumes is going to happen. Why disappoint them?

Tuesday, April 7, 2015

The Right Agent For the Job

What happens when an agent completely bungles an incoming call at your call center? This may be the caller's first experience with your business. A well trained sales agent just isn't going to be as effective if they're getting calls from your "Tech Support 2" queue. Your techs may flub sales calls. Obviously you can't just have calls ringing the phone of anybody who connects to the system.

This is the way simple PBX queues often work.

If you've only got three queues and distinct groups of people who should be answering those calls, the PBX queue functionality is probably fine. If you have agents logging into multiple queues, you need something more sophisticated. A call center ACD system that offers skills-based routing will let you:

Anybody who gets logged in can get the call. Anyone who is sitting at a phone that's been marked as ready for a queue might wind up talking to your Quality Assurance auditor.
  • Give calls to certain agents first, only giving calls to others if nobody is available
  • Let you assign agents to multiple queues, but only the ones they are qualified for.

As you can guess from the name, skills-based routing depends heavily on the definition of skills. Languages can be skills. Proficiencies and what you would normally call skills are skills.

You want to make sure that your skills are defined well-enough that you get enough flexibility and precision. For example, you might define skills like "Spanish", "Customer Service", "Sales", "Tech Support 1", "Tech Support 2", and so on. Then every agent who can speak Spanish will receive the "Spanish" skill. You assign every English-speaking agent the "English" skill. Your best technical support people might get "Tech Support 1" and "Tech Support 2", while the agent who has just learned the system might get only "Tech Support 1".

In a skills-based routing queue environment, you can think of a queue as a set of skills. When you're creating your queues, you then pick the needed skills for each. For instance, the "Tech Support 1 - Spanish" queue will get the "Tech Support 1" skill and the "Spanish" skill. Only agents who have both skills will be put into that queue. This avoids the problem of a non-Spanish speaking agent getting a Spanish call and fumbling it badly.

call center Queue skill assignment

Skill priorities allow you to distinguish between agents with the same skills. For instance, you might have a "Tech Support 1" queue and have several of your "Tech Support 2" agents working it, just to make sure calls get handled quickly. Or maybe the "Tech Support 2" queue isn't very busy. In either case, you probably want to make sure that the "Tech Support 2" skilled agents only get calls if a "Tech Support 1" agent isn't available. Or you want to keep your "Spanish" + "Customer Support" agents in reserve for a call to "Customer Support - Spanish", and only take calls in "Customer Support" if necessary. Another possibility is that you want your supervisors to only get a call if nobody else is available. The skill level allows you to specify which agents get calls first, and which ones will wait longer.

Along with queue priorities, a full-featured call center ACD system should provide you with all the tools you need to make sure calls get answered by the right agent in the right order.

Thursday, April 2, 2015

When It Absolutely, Positively Has to Get Through the Queue

Imagine you have calls coming in that must be answered as immediately as possible. You also have calls coming in that don't. Or you have a type of call that should be answered as a priority if it has been waiting less than 30 seconds, but after that it can wait like any other call. What tool would you use?

Some people just get priority
In these cases, queue priorities are what you need. In the Asterisk world, this is also sometimes referred to as queue weight. The idea is that one queue is more important, and if an agent can receive calls from more than one queue, the queue with greater priority should have its call handled first.

Why would you want to do such a thing? Well, you could have a queue that Gold Club members go into, and regular members go into the other. As long as a Gold Club member is waiting the next available agent should handle the call. You might also be handling contracts with differing levels of importance. There are a lot of reasons.

What are the pitfalls?

The biggest problem with setting one of your queues to always get answered first is agent starvation. If your agents are always busy serving the one queue, calls to another queue may never get handled, with calls abandoning or timing out before your agent can get to it. It's sort of a nuclear option for call handling, so make sure you've thought it through before using this option.

You can avoid agent starvation by having calls from another queue time out and continue on to a queue with an equal (or higher) priority level. That may negate your reason for using priority in the first place. It can be a good safety valve, though. Dynamically reassigning agents is another possibility, if you have good live reporting and call center ACD software that allows this to be done.

To avoid confusion with agent skill priorities, consider how ties are broken:

  • Queue Priority - if you have one agent waiting and a call in two or more queues, queue priority decides which call gets answered next. With equal priorities, the longest waiting call should get answered.
  • Agent Skill Priority - if you have one call waiting and two agents ready to take it, agent skill priority decides who gets the call. If the priorities are the same, then the agent who's waited the longest should get it.