TMCnet - World's Largest Communications and Technology Community




technotalk.gif (1245 bytes)
February 1999

For Want Of A Nail…


Sifting through the detritus of the two weeks worth of mail that awaited my post-holiday return to the office, I discovered a package which, while too small to be the Ark of the Covenant, was nonetheless quite imposing. Hoping, in vain, that it was some belated holiday chocolate, I tore through the sturdy wrapping to discover, instead, a weighty tome entitled Call Center Continuity Planning, by Jim Rowan and Sharon Rowan of Voice Recovery Services.

Continuity planning, another term for disaster recovery, is a topic that should be of great concern to every call center. Call Center Continuity Planning, then, presents a methodology, some of which I'll discuss here, that, if adopted, can help ensure, in the event of a disaster, the perpetuation of a company's essential business functions. For those of us in the call center industry, that means preserving the call center's sales and service capabilities, and, by implication, its ability to maintain and/or develop customer relationships under adverse conditions.

Since customers are the real heart of any company (no customers, no one to sell to, and thus, no reason to make a product), implementing a plan that will help guarantee near 100 percent uptime for the call center should a calamity strike should be every company's top priority. Indeed, customer relationship management strategies arise, in part, out of the daily activities in which the call center is engaged - a customer can hardly place an order or receive tech support if the call center they would have called is down because of a power outage. In that kind of situation, there's a good chance the order could be placed with a competing company or a customer could be lost (perhaps a highly profitable one) because he became dissatisfied because he was unable to reach a support rep.

Domino's Pizza, for example, may make and deliver pizzas, but should their phone lines be severed, customers would be unable to place orders - no need to make pizza. That particular Domino's Pizza branch would, effectively, be out of business until phone service was restored. Factor in the cost of remaining idle versus having a normal revenue stream defray and/or exceed overhead and the financial damage begins to accumulate. There's also the (albeit hard to quantify) damage to Domino's reputation - customers who couldn't get through, for example, might dial Little Caesar's, and having sampled their wares, might well decide to never call Domino's again.

To further illustrate the need for disaster recovery plans (which, by the way, should inherently enable a company to not only weather the immediate disaster, but also to return to normal operations), here are some rather mordant statistics quoted by the authors of Call Center Continuity Planning: "The United States National Archives and Records Administrations reported that only 43 percent of businesses that suffer a disabling disaster ever resume operations. A disabling disaster…shuts down a company long enough to have a profound impact upon the company…. Of the 43 percent that survive the initial disaster, only 29 percent are still in business two years later. Turn this statistic around, and you will see that of businesses that suffer such a disruption, about 57 percent never resume operations. And about 71 percent of those that resume cannot continue as long as two years. Only about 12.5 percent of all such unfortunate businesses have the capability of continuing for more than two years after the disaster."

George Herbert's words spring to mind: "For want of a nail the shoe is lost, for want of a shoe the horse is lost, for want of a horse the rider is lost." That nail is your disaster recovery plan and of course, your company is the hapless rider.

The term "disaster" encompasses more than just natural calamities; it also signifies happenings which negatively impact a company's ability to maintain its essential business functions (as defined above) for a given period of time. This interruption implies a loss of short-term revenue, but might also impair the company's future earnings potential. As a result, computer viruses, corrupted data or equipment failure, sabotage, rioting, disgruntled employees with guns…gremlins named "Spike"…can all be deemed disasters.

Expect The Unexpected
Prevention is undoubtedly the best medicine - installing uninterruptable power supplies, backup generators, air conditioning, hot-swappable components, regular database backup and storage at offsite facilities, industrial computers and mirrored/redundant processes are but some of the proper steps toward maintaining a stable computing and telecommunications environment. You'll also need automated equipment and human maintenance checks to alert you to possible or imminent danger. Our online, searchable 1999 Buyer's Guide is a great place to find the names of vendors specializing in these kinds of systems (CTI magazine's online Buyer's Guide is another good source.)

The stages of disaster planning, as expressed by the authors, involve the following:

  • Problem recognition - To succeed, disaster recovery plans require support. You might want to begin by cataloging expected resistance to plan development/implementation so as to better overcome objections. The authors do a great job of debunking some of the more common objections to contingency plan creation.
  • Need justification - If financial reasons don't provide sufficient impetus, legal implications surrounding the company's failure to institute a workable contingency plan may help prove need.
  • Management buy-in and support from the senior levels - Backing from upper management is necessary to overcome internal politics, resistance and ennui; without it, the plan won't happen.
  • Dollar, time and resource commitment - It takes time and money to create a plan, as well as to ensure the necessary resources are in place when the disaster happens. The authors suggest enlisting the support of the CFO or another senior member of the accounting department, as well as making sure an accountant is on the recovery team to approve capital outlay at the time of need.
  • Recovery team selection - who does what, when, where, why and how during the actual crisis. Positions should be assigned on the basis of experience, ability and personality. Team leaders should be able and accustomed to making decisions quickly; his/her decisions, moreover, are not subject to debate and should be imbued with the authority to make those decisions stick. Provisions for backup team members and leaders should be made so that the plan isn't crippled by the absence of any given individual.
  • Business impact analysis - This is where you detail the essential areas of the business, i.e., those buttresses upon which rest the continued health and wealth of the company. A couple questions to keep in mind during this stage: when will the negative impact be felt and how much loss is acceptable? The proper completion of this stage will be a team effort, the members of which should be selected on much the same criteria as above.
  • Risk analysis - What disasters are more likely to happen to your operation than others? If you're located in Omaha, Nebraska you can probably cross tsunami off your list. An earthquake in Los Angeles or a hurricane in Miami are a little more likely. Given the wide variety of possible disasters, the authors suggest categorizing and prioritizing the ones most likely to affect your operations. Built into this process are guidelines to help you determine what constitutes a disaster and what doesn't, i.e., when to enact the plan.
  • Plan contents - The authors focus on call volume management in their discussion of disaster recovery. This term simply implies these questions: what do I do with my incoming calls when a disaster hits; or what constitutes an effective, efficient way to redistribute calls such that my core processes are minimally affected? This section of disaster planning also involves provisions for emergency communication, the acquisition of replacement equipment, if necessary, from your vendors, as well as the installation and preparation of that equipment for use during the crisis. I'll cover this point in a bit more depth later.
  • Responsibilities of the various teams - Several teams should be created to manage discrete portions of the crisis, e.g., a disaster site recovery team that's responsible for overseeing repairs at the afflicted site; an interim call handling team for assisting and coordinating the activities of your supporting call centers; a hot site recovery team assigned to each facility to which your operations might relocate; a team from each department should be detailed to preserve its critical functions; and external liaisons for each team so that tasks which touch more than one team can be smoothly handled.
  • Backup procedures - This involves data backup as well as hard copy inventories and off-site storage of important information.
  • Disaster implementation tasks - Make a checklist for everything you want to happen - the shutdown of key equipment, or the transfer of calls to a hot site are two examples - so that anyone can figure out what to do. Document and assign tasks on a team and individual level so that everyone is aware of their responsibilities. Since this is the part of the plan that is directly involved in managing the crisis, make sure procedures are general enough to be flexible, but specific enough to prevent confusion. Plan testing will help work the kinks out. The authors also suggest implementing an IVR so that employees can call in to figure out what's going on and what they're expected to do.
  • Return to normal operations - This involves getting people back to work in a safe environment, bringing the LAN and telecom infrastructure online, returning calls to the site, etc.
  • Postplan activities - The assessment of how well the plan and people performed. This is also the time to improve the plan on the basis of real results, not those gleaned from a testing situation.

A couple of important corollary activities involve:

  • Plan testing - Should a disaster hit, you don't want people running around wondering what to do. You want them to know immediately what action to take. The only way to achieve that clarity of thought and deed is to drill the procedure into them. It's probably best to rehearse the new plan at announced intervals, but once everyone knows what they're doing, spring it on them without warning and make it as real as possible.
  • Plan maintenance - Every business changes over time. People quit, are fired and/or hired. New technologies are installed. Your disaster recovery plan must account for these changes - otherwise it's utterly useless. The best way to stay on top of organizational change is to update the plan every week, month, quarter - make it a habit, make it a process.

Managing Call Volume
As the authors suggest, there is no single "cookie-cutter" solution for a given call center to take, tailor slightly and implement. The best approach is to analyze your business' call types, assign difficulty factors to each type of call (several worksheets are provided as guidelines), and then decide how you want to disperse inbound calls when your primary site goes down. Some of their suggestions include switching to a(n):

  • Interactive voice response unit: We're all aware of the limitations of IVRs, as well as some customers' frustrations in talking to a machine. Still, for a short time, IVR call handling for noncomplex calls (account queries, flight information lookup) might suffice.
  • Real-time overflow to an outsourcing partner: This technique is especially effective if you have an existing (perhaps close) relationship with a teleservices agency. Handling the majority of your calls should be relatively easy since they're already familiar with your products and procedures and should also have the resources to quickly ramp up to handle more calls.
  • Interim Call Handling (ICH): This setup is similar to the outsourcing contingency, except that this company doesn't regularly handle your overflow calls. You would need, therefore, to provide a CSR script for each type of call routed to the ICH. The ICH would be responsible for deploying sufficient resources to meet your service level goals, which you may or may not have altered due to the emergency. How they do this is, of course, extremely important and a good subject for further investigation. The results of calls handled by the ICH are usually saved to a standard database for download when your systems are back online.
  • Hot site: Some companies provide "call-center-ready" sites that can be rented for a specific time when needed. You will need to arrange with your telco for calls to be switched to that site, and for your designated personnel to reach that site, get it up and running and then manned for call handling. If your normal call center is technologically sophisticated, there's a good chance that the hot site will only provide the bare minimum for handling customer calls. Make certain the people you select to staff that site are prepared.
  • Company cold/warm site: This is a backup call center that has the potential to accept incoming calls, but not without substantial "heating up." In this case, you'll probably have your technology vendors send new equipment to that site, have MIS people there to install it, get the computer system running, have the telco install phone lines and route calls to it…it's a big task, especially if time is short.
  • Virtual/multisite call center: The authors discuss this option only from the perspective of having the telco route calls to agents' homes without a degree of network intelligence. In truth, distributed/virtual call center solutions can be quite robust, and many companies from the product side (IEX, GeoTel, Teloquent, Genesys) and services side (AT&T, MCI, Sprint), to name a few, specialize in the creation of networks of call centers. If this topic interests you, I'm discussing it in a series of articles published on TMCnet.

In short, settling on a plan to ensure the preservation of your core business functions is not an easy task. It takes a great deal of internal preparation, planning and teamwork, as well as coordination with outside vendors. I would be remiss if I even suggested that this article did more than provide a brief glimpse of the complexity involved in planning for disasters. If you're interested in further pursuing the topic, I'd suggest contacting the authors of Call Center Continuity Planning at [email protected], lest, for want of a nail, your business be lost.

The author may be contacted at mvartabedian@tmcnet.com.

Skill-Set Forecasting Addendum

In my October 1998 article entitled "A Little Of This, And A Pinch Of That", I discussed possible benefits of the then recently announced skills-based workforce scheduling solutions available from Blue Pumpkin, IEX Corporation and TCS Management Group.

It has since come to my attention that Pipkins, Inc. also has a skills-based scheduling solution, called Maxima Advantage, which forecasts call volumes and handling times by ACD queue.

In the Pipkins' approach, each queue is equated to a user-defined agent skill set, called a serving team. In the ACD (and the workforce management product, for that matter), each agent is then assigned to a serving team, which is associated with a particular ACD queue, like customer service or sales.

To generate the schedule, Maxima Advantage uses the anticipated call volume, handling times and your ideal service level to forecast staffing requirements, i.e., the number of agents needed per skill set to meet service objectives. Maxima Advantage will then generate an agent schedule based on the parameters you define: e.g., agent work preferences, days off, flexible start/finish times, duty lengths, breaks and lunches, etc.

Maxima Advantage can also enable multiskilled agents to work in different serving teams (receive calls from different ACD queues) at different points throughout the day. For example, an agent who can handle tech support calls for more than one product (in this case ACD queues are differentiated by product, so agents would be assigned to serving teams/skill sets in a given product; a multiskilled agent, therefore, could handle calls for multiple products) may answer calls for one product for two hours, switch to handle calls for a different product for another two hours, and then after lunch, be assigned to a clerical duties "queue"/skill set.

The skill-set approach to workforce forecasting/management becomes especially powerful in a call center with many agents with multiple skills. The concept of skill sets condenses the complexity of managing a diverse workforce by collecting agents with similar skills into a single group; agents in that skill set (serving team) can then be scheduled more traditionally (as explained above). By implication, performance reporting also becomes simpler since service level per skill set can immediately be determined. Discovering how well individual agents adhere to the forecasted schedule also becomes easier because the supervisor or manager has already defined the agent/serving team relationship.

Maxima Advantage runs on Windows NT 4.0 server; on the client side it runs on Windows 9x or Windows NT. It uses Oracle for the relational database, making the decision on how much historical data to keep merely a question of disk size. For more information about Pipkins and Maxima Advantage with Skillsense, call 314-469-6106 or visit www.pipkins.com.

Technology Marketing Corporation

2 Trap Falls Road Suite 106, Shelton, CT 06484 USA
Ph: +1-203-852-6800, 800-243-6002

General comments: [email protected].
Comments about this site: [email protected].


© 2024 Technology Marketing Corporation. All rights reserved | Privacy Policy