Posted on

Schedule the Sale

Callbacks can be a great way to give that last push to get your sale. Callbacks can also drain the performance (and profitability) of your call center. For such an important tool, they can be woefully misunderstood. Your call center software likely has a number of settings surrounding callbacks. Make sure you understand what your agents are doing with their callbacks.

There are two primary types of scheduled callbacks: Continue reading “Schedule the Sale”

Posted on

Give Your Callers Exits to Keep Them From Waiting

In an emergency, it is necessary to fly to the door.

Waiting in an inbound queue until the next available agent is prepared to accept your call is an inevitable situation. If you’ve ever needed to call your service provider to add/cancel services or to place an order over the phone, you will run into this scenario. Using some of the available features in the Q-Suite, as a call center ACD administrator you can help ease the waiting times of your customers by providing manually triggered exits for the caller.

Continue reading “Give Your Callers Exits to Keep Them From Waiting”

Posted on

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.
Continue reading “The Startup Call Center – Be Nimble, Be Quick”

Posted on

3 Minor Annoyances of Not Having Physical Control Over Contact Center Hardware

A situation came up this week where we needed to collaborate with a server colocation in order to rebuild a server. Overall, the process was very smooth and went by without much of a hitch. However, not having full physical access to the server definitely slowed us up a bit. Here’s why:

  • Communication Delays – Regardless of how quickly and efficiently your colocation company works, there are always going to be delays, even if they are extremely minor. Every time something was completed on their end, they would respond to an open ticket, either waiting for further instructions or a simple approval. If you housed your server on site and had a dedicated technician working on it, these small communication delays can be eliminated and your contact center can be back in action that much faster.
  • Server Layout – Ideally, your servers for a particular contact center would be racked together in a logical order, connected to common networking equipment, and likely all accessible via some type of switching box, like KVM. While this may entirely be the case at the colocation, it’s not a 100% certainty that your servers will be arranged in this fashion. Having multiple points of access to the servers can cause issues if, for instance, the power strip that has 3 out of 6 servers on happens to malfunction.
  • Server Room Access – You have no control who has access to the room or rooms where your servers are located. This can cause small random issues like in our particular instance this week where somehow an ethernet cable became unseated on the primary interface right before we were about to reintroduce the newly built server into the contact center. This caused bad things to happen but we caught it in time. We are not sure exactly how it happened, but cables that lock in place do not magically become unlocked. Someone likely accidentally moved or hit the cable enough to cause the network disruption. Once we opened a dialogue with them, someone needed to go in and reseat the cable, which took much longer than it would have if the servers were in house.
You can see fairly clearly that the three issues above are pretty minor overall and none were catastrophic in nature. I’ve talked before about using a hosted platform and how great it can be for certain people and my stance had definitely not changed there. But as with everything in life, nothing’s perfect.
Posted on

Rise of the Robots – Outbound Dialing Part 5

robo-dialing

If preview dialing is slow and methodical, and predictive dialing is dialing on steroids, you have to wonder how to characterize auto dialing.

To be clear, here we’re discussing auto dialing that doesn’t involve predictive dialing. That’s a special case of an auto dialer that attempts to connect agents to calls as soon as possible. There are cases where you don’t want to involve an agent, or only in certain cases. You may need an auto dialer.

An auto dialer is usually used in three cases:

Continue reading “Rise of the Robots – Outbound Dialing Part 5”

Posted on

One Way to Stop Overloading Your Telephony Server

Too much traffic can bring down your call center

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.

Posted on

One Number, One Big Problem

Where do you want your IVR to take the call

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. Continue reading “One Number, One Big Problem”

Posted on

How to Avoid using a “Courtesy Disconnect” as the IRS Calls it.

Tomorrow is the IRS tax filing deadline if you live in the US. If you call for help and their system is overloaded it will hang up on you, which they call a ‘courtesy disconnect’. Which brings me to back to a recurring topic on this blog and others which boil down to mistakes in IVR design.

If you haven’t seen the clip of This Week Tonight about the IRS take a look. The ‘courtesy disconnect’ segment starts around 2:23. But read on below for some suggestions for dealing with an overloaded system. Due to language this is clip is not safe for work:

[youtube //www.youtube.com/watch?v=Nn_Zln_4pA8?rel=0]

So it’s understandable that near the tax filing deadline the IRS would have a higher than normal call volume. Something that can happen to any company which should be planned for and tested prior.  Not being in the US I have never called the IRS and have no first hand experience but after searches and reading a number of articles it sounds like they are hanging up after a person has been waiting for a time. Of course the IRS can get away with this as their customers can not leave and go elsewhere. But if they wanted to improve customer relations they could implement this differently. I would suggest any of the following to improve similar situations:

  1. Max Caller Limit on Queues. This ensures the limiting is done prior to the caller waiting and any caller over the limit will hear a message to call back at a later time.  Of course one has to be careful here if the queue times out and sends to another we could end up in a situation like the IRS is doing and hangup up after a caller already waited. So it should only be on the first queues a caller can enter.
  2. Enable Queue Callback Feature. This is where the caller in the queue is offered to leave a callback number and is later called back, usually keeping their position in the queue. Be sure to combine this with option 1 as having thousands of callers leave a callback number but never get a call is just as bad as a courtesy hangup.
  3. Common Questions and Answers. Often callers have the same question and if the IVR can provide these answers it can save the queue and staff answering those calls.  This is especially useful in cases for general status which could be due to a temporary outage of a service for example.  These can and will cause an influx of callers all asking the same question until that’s resolved.
  4. Higher Staffing Levels. Not easy as it often requires hiring new people and that takes time.  However in this case it’s known this time of year will have increased call volume so having more staff to answer the calls is the simple, although not cheap, answer to improve the situation. Just ensure your system is capable of scaling to the needs and the hardware can power it. Alternatively go for a hosted system to avoid the hardware costs for a yearly surge which I am sure drops significantly the rest of the year in cases like this.