By Peter Lyle DeHaan, PhD
[See Connections Magazine’s website for Part I of this article.]
We developed a check list of items to be addressed as we cut each group of accounts. While the list was fairly self-evident when planning the transition from afar, we knew it would need to be documented, so that in the turmoil, confusion, and emotion of the moment, nothing would be overlooked, skipped, or done out of order. (Actually, the checklist covered items to do during the preparation stage, as well as tasks to complete after the cut, but the critical portion was the things to do during the cut, when timing and efficacy was critical.) The checklist was as follows:
Compare the answer phrases: We did a last minute comparison of answer phrases between the two systems to make sure that no accounts were overlooked or missed.
Enter on-call information: On-call information is dynamic and changes on a daily basis. The on-call schedule which was exported from the old system, weeks prior, was obsolete and out-of-date; the current list needed to be entered manually on the day of the cut.
Enter temporary information: In the same manner, temporary information from the old system needed to be entered into the new system.
Program the system reminders: The old system reminders, or queue, were programmed into a new system on the day of the cut.
Program auto-delivery: Likewise the auto-faxing and emails were entered for those clients who received their messages via fax, email, or remote printer. Fax voice mail instructions: Our message center clients who picked up their messages via voice mail would be converted over to a new system’s internal voice mail. This required a different check-in procedure and command sequence, which was faxed to them the day of the cut or one day prior. Reroute calls from the old system to a new system: Since we had a switch on the front end of both the old system and our new system, it was merely a programming function to redirect the DID numbers to the new system at the desired time.
Test each account: Just to be safe, we called the DID number for every account to make sure it rang in and that the right answer phrase was correctly displayed.
Fax or email messages from old system: Any client using fax delivery service was faxed all pending messages which were still in the old system. The same applied for clients getting messages via email. Transfer pending voice mail messages: Although we performed each cut at a time when few messages were in voice mail (mid-morning or mid-afternoon) some messages were invariably pending; these needed to be re-recorded into the new system.
Remove the “reminders” and automatic delivery options from the old system: Since the old system was still running (to serve the remaining clients not yet cut over) the system reminders and auto-delivery schedules were removed from the old system to avoid confusion or potential problems.
Remove the message prompts from the old system: Likewise, we did not want a message accidentally entered into the old system if the account had been switched to the new system, so we removed the message prompts from the old system soon after the accounts were cut. Remove programming from other systems as time allows: Not only did the remaining programming need to be deleted from the main system, but programming also existed in our fax server and voice mail system, which needed to be removed.
With a clear-cut procedure in mind, we could confidently begin our conversion. The first phase was actually our “pre-cut” and was done one month before our targeted main cut date. For this, we switched over a group of 70 accounts from one market. These accounts had enough traffic to keep one telephone service representative (TSR) about 70% busy, which was ideal since they were learning and needed practice to get up to speed. We needed to staff one person on the new system around the clock and made sure to work everyone into the rotation. These were short shifts, generally two to three hours each. Some TSRs were immediately smitten by the new system and never wanted to take another old system call again, while others wanted to stay with the old system as long as they could. Within three days every TSR had experienced at least one shift on the new system.
With the pre-cut behind us, we were with nervous anticipation, ready to begin our migration. The cut was to be done in stages, by transferring clients in groups at various times over the course of a month. This was done for four reasons. The first was that by doing the cut in groups, our management team could focus intently on those specific clients during the course of their transition. Secondly, if we found that we had a programming problem, training oversight, or call distribution dilemma, it would be much easier to address. Thirdly, our staff could be exposed to a new system gradually over time and in small doses rather than intensely and all at once. Lastly, by doing the cut in stages, we could, at any time, delay or speed up the process based on how we were doing. Once our staff’s initial jitters were over from the pre-cut, they needed more traffic to avoid boredom; so, a few days later, we cut over another small market, which had about twenty-five accounts.
By mid-month, two weeks into the transition, we were feeling pretty good about our progress and success, celebrating it by cutting over 100 more accounts from a third market. Unexpectedly, this made our staffing of the two systems more difficult instead of easier as we had anticipated. We realized that rather than being able to follow a strict, pre-determined staffing schedule, we needed to be able to dynamically move TSRs between the two systems as traffic warranted. At this point we were well poised to switch over the remaining clients.
Three weeks after our initial cut the majority of our staff were encouraging us to “go ahead and cut everything.” By adding a fourth market, we would more than double the amount of traffic on the new system. We went ahead and converted this group, thinking that we would double our staffing on the new system as well. Unfortunately, we had assumed that the traffic patterns would be the same for this group of clients, but they weren’t. These clients impacted our day shift minimally but hit our second shift significantly, as most of their traffic were after-hour calls. Later in that same week (once we had made the proper scheduling adjustments) we cut over another small market. By now our staff was confident in their skills and getting anxious to complete the cut. The following week, we cut the remaining market–which represented about fifty percent of our total traffic. Although this was by far the largest group, it was done with a high level of expertise, little fanfare, and was fairly anti-climactic. It was also completed on the exact day we had planned on, some five months prior!
Four months after the cut was complete, we repeated the procedure with another office, moving them off of a separate system and integrating them into our new system. Then we began the process of optimizing our new system by implementing the many new features and services that it offered.
Optimizing Your New System
After the cut, once the staff is up to speed, the clients are happy and the proverbial dust has settled, is the time to begin to optimize your new system. This effort involves both fine-tuning account programming and introducing new features, as well as updating TSR procedures and practices.
We consider this phase to be a work in progress, one which will continue into the foreseeable future, as long as new features and capabilities are added to the new system platform. The premise from which our optimization effort arose was a consequence of our key paradigms for installation and implementation. One was that we would import our old system database into a new system; the other was that we would make a new system work as much like the old system as possible–at least initially. Just as there is an exception to every rule, there is a postscript for every paradigm. As such, two new system features received a special dispensation to be exempt from our requirement to make the new system work like our old one. To make these two features work the same on both systems would have been convoluted and prone to error, as well as inefficient. It made sense, in these two cases, to abandon idealism and adopt an attitude of pragmatism. As such, two new features were already implemented and in place at the time of the cut. Unfortunately, because of a limitation in one of these features, we have since abandoned it and adapted a different procedure to accomplish the same function.
Because of our decision to import old system client information directly into the new system, we had some post-data-transfer clean-up to do. Mainly this included inserting and deleting pages (which could not be done effectively in the old system) and making sure each page had a descriptive heading to be displayed in the index. We also did some editing clean-up, which is always an ongoing effort and required whether the data is imported or manually entered.
With these items addressed, we soon were at a point where we could begin to implement new features. With each, our procedure was the same: study the feature, program a demo account to showcase it, test it and experiment, obtain input and ideas from our leadership team, determine how we will and will not use the feature, and document its programming and functions. At that point we implemented it for one or two clients to ferret out any problems or oversights. Then, upon successfully completing this preliminary step, we rolled it out for all clients to whom it applied. In some cases this procedure was easy and almost inconsequential; in other instances, it was a critical and necessary effort in order to insure success.
The actual list of features will vary from system to system and will also be greatly influenced by the goals, objectives, and operating philosophy of each company. Regardless, the features should be given a priority based on value to the staff and clients, as well as their impact on overall operations and the bottom line.
Peter Lyle DeHaan, PhD, is the publisher and editor-in-chief of Connections Magazine. He’s a passionate wordsmith whose goal is to change the world one word at a time. Read more of his articles at PeterDeHaanPublishing.com.
[From Connection Magazine – November 2000]