By Peter DeHaan
The successful introduction of any new equipment is a balancing act, a series of trade-offs between many conflicting and mutually exclusive goals (e.g. “we want it to be installed quickly, for minimal cost, and without impacting service, causing frustration to the staff, or introducing a billing disaster”).
As I approached this task, I too committed to do it right, with no impact on our clients, no tension among our staff, and no grueling 80-hour work weeks prior to the cut. To achieve this technical nirvana, I sought the advice of those who navigated this trail before, mixed in my own experiences and pragmatism, and topped it off with total confidence in a staff who could be flexible, patient, and supportive in the midst of any crisis and challenge.
As I talked to those who preceded me on the new system adventure, I always asked the same series of questions: 1) How did your cut go? 2) What went right? 3) What went wrong? and 4) What would you have done differently? Without exception, all those questioned had several things they would have done differently (less the reader has any doubts, I did not reverse this trend). This article will detail the manner in which we orchestrated our transition to a new system, not because it is a plan to be followed, but rather because it may provide a framework on which others can make their own plan. Perhaps it can even help someone to experience the perfect cut!
This article will cover things to do: before the equipment arrives, how to install the system, importing your database, cutting over the new system, and finally optimizing it. It is fair to state that the optimization phase will likely never be complete, because it will be both evolving and ongoing for as long as your vendor supports the system and introduces new features and services.
Preparations for our new system began several years ago, long before the contract had been signed and even before the need to replace the old system existed. Some of these preliminary tasks were unique to our company, but most are generic.
Optimize DID numbers: We had the distinct privilege (or perhaps burden) of having DID trunks from 16 different cities (plus several hundred groups of toll-free numbers). As you might imagine, we had many numbering conflicts, resulting in an increasingly complex list of offsets and translations to tie every DID number to a unique account number. Therefore, several years ago, we embarked on a “DID Optimization Plan” to eliminate all numbers which produced code conflicts. While there was no technical need to make this change, doing so greatly reduced confusion and significantly simplified our numbering plan.
Change PIN (account number) assignments: A second element of the “DID Optimization Plan” was to make the PINs (account numbers) match the last four digits of the DID number. Since our numbering plan evolved over time; and because the old system initially went no higher than account 3199, we ended up with a jumbled numbering plan and desired to clean it up; this required changing the PIN on the majority of accounts. This was done over a three year period and taken in small steps. Again, there was no technical reason to make this change, but it was done for simplicity sake and to reduce errors in correlating DID numbers with PINs. This effort would pay huge dividends during the migration to our new system as it eliminated what would have been a great deal of confusion.
Remove all unused accounts from the old system:
We have in place a rigorous procedure to remove all accounts from former clients after each billing cycle. Unfortunately, any account coded for “company use” seemed to stay in the system forever. Even though we conducted periodic audits of these “company use” accounts, we still found hundreds of accounts which needed to be purged from the system; most had been reserved by/for the sales staff and forgotten about. Every unused account would result in unnecessary work during the data-entry phase; therefore, they were rigorously sought out and eliminated.
Delete old voice mail boxes: When a client cancels or changes service, there are many systems which can be impacted. All too often the main account would be removed from the main system, but programming in secondary systems would be overlooked. All clients had a voice mail box for a custom auto-answer recording or a greeting (some had two greetings for different times of the day) and many had another voice mail box for message retrieval. As more employees became involved in the programming process, the greater the likelihood that a mailbox would remain programmed long after it was no longer needed. Six years worth of unused and forgotten mailboxes existed in our voice mail system. Cleaning this up was a step that we skipped until after the cut; had we handled it early on, it would have helped make the cut go smoother.
DEprogram fax delivery: In similar fashion our fax delivery system had accumulated obsolete programming. We went through it account by account, deleting all programming which did not tie back to an active account and commenced billing on any remaining accounts heretofore not billed. Remove old “directories”: Likewise clients’ directories, or lists, have a way of sticking around forever. We audited these lists and removed those no longer needed. Though we were successful in removing all directories relating to off-service clients, we inadvertently retained a few directories for existing clients, but for whom the information was no longer used. It wasn’t until after the directories were imported and optimized that we realized they were obsolete.
Phase out hardwire (concentrator) lines: Though most telephone answering services have long ago phased out their hardwire lines, we had elected to retain them and had not taken pro-active steps to convert them to call-forwarding. A call-forwarding client can change services in a few seconds; a hardwire client takes several days to change services and tends to be more long term. Since most new systems cannot effectively accommodate hardwire accounts, we needed to convert all hardwire lines to call forwarding. This had been a work in progress for two years and though we had gone from 16 concentrators down to three, a few stragglers had still not converted by the time of our cut!
Identify accounts with special needs: Such as unique configurations, or unusual programming. Every anomalous situation presents a special case to be dealt with during the cut (and a likely problem to cause frustration). Whenever these abnormal circumstances can be converted to the norm, a potential problem can be averted. At the very least these types of accounts should be investigated and documented so that the transition does not leave them behind or, worse yet, unserved.
Make sure your billing is in order: We took strides to raise rates on low margin accounts several months prior to the cut. Conversion time is not the time you should be giving your clients any surprises in their bills. Also, we made sure that everyone was being billed for all of the services they were using. This served to greatly reduce confusion at the time of the install and cut. It also added hundreds of dollars in monthly revenue.
Make necessary billing adjustments: We learned that we could no longer bill dialouts in the same way with the new system. By knowing this ahead of time, we were able to make the adjustment in our old system well before the cut. This too added some additional revenue and reduced surprises when the first bills were generated using the stats from the new system. It was our plan to accomplish the preceding ten steps prior to the equipment arriving. Though we were very close to realizing our objective, a couple of items seemed to hang on forever. Although delaying completion of these goals did not directly impact our cut, they did serve to take away from time allocated to other tasks which needed to be done later in the process.
If I had it to do over again, I would have begun preparation even earlier and would have worked harder to stay on schedule with those initial tasks. It is not too far from the truth to state that the best time to begin preparing for your next system is just after your new one has been installed.
With these preliminary items completed and out of the way, it was now time to actually install the equipment. Two paradigms guided this process; the first was that we were going to export the key system data elements from our old system and import them into the new system. Second, we wanted to make a new system look and operate as much like the old system as possible–at least at the time of the cut (we would make changes later after everything had settled down). With these two guiding principles in mind, we mapped out the following steps:
Determine the cut date and develop a schedule based on it: We picked the optimum date we wished to cut over to the new system and scheduled backwards from that–our cut date was September 27th. There was nothing magical about that date, but summer would be behind us (typically a busier time with greater staffing issues), the order-entry accounts would not have yet picked up for Christmas, and it would be the end of a billing cycle. We would do a mini-cut one month prior to that. Data import would occur in July; the initial telephone service representative (TSR) training would be in June; supervisor training in May, with the system being installed one week prior. Having that schedule in place also took the guesswork out of the timing for the payment schedule to vendor and our capital requirements from the bank, so we were able to accurately plan for that as well.
Inform your staff: An important and critical early step was to begin involving our TSRs. It was imperative to get them on board and behind this project if it was to be successful. We let them know that a new system had been ordered; it would operate much like the old system, but would also offer many new and better ways of accomplishing our work. We also told them that we had plenty of time to prepare for it and announced the date of the cut. Throughout the process, we kept them up-to-date on developments and progress. We operated on the premise that although change is scary, change that is made in small increments is understood, and if within their control, is acceptable and reasonable. This premise proved to be correct.
Work with your vendor coordinator: It was vital for us to develop a rapport with our vendor’s install coordinator. She was instrumental in helping everything to go smoothly and on schedule. We prepared a great deal of information for her about our site, our operation, our plans, and our schedule. Be careful to defer to your coordinator’s judgment and experience as much as possible, but at the same time, you may need to assert some of the critical paradigms, goals, or philosophies that are non-negotiable. For example, we were the first to export data from our old system and import it into the new system; there were many who strongly advised against doing so.
Also, recognize that your install coordinator has to balance your needs with the needs of the other installs she is overseeing. Therefore, we attempted to be patient and respectful of this by providing her all the information she needed as soon as possible, giving her time to address our needs as well as the needs of the other installs she was coordinating. I wanted her to be 100 percent focused on our site during crunch time, so we were sure to be patient when she needed to give her attention to other sites during their critical time.
Make room for the equipment: We planned where the new system would go and made room for it. Space was prepared to mount the necessary blocks and jacks. Fortunately, we had enough outlets nearby which were already connected to our back-up power system; otherwise, we would have had to call an electrician to make the necessary changes. Though you may be tempted to defer much of this to your installer, do as much preliminary work as you can before hand. This way your installer can focus on the new system install and not be distracted by ancillary issues.
Go through equipment training: We worked with our installer as much as possible (without getting in his way) and provided as much assistance as we could (knowing that sometimes the best help may be not to help). As the system was installed we got a thorough overview of it, the cards, and the system controls. We worked with him to inventory our spares and installed them to make sure they also worked. Documentation always seems to be a step that is put off; however, when the installer is on site, and has just installed the system, this is the best time to document the wiring, ports, blocks, jacks, and other key elements. This will be critical later on. Any omission in this area will cause serious problems sometime in the future–it’s just a question of when.
Go through supervisor training: We scheduled our installer and trainer on subsequent weeks. This allowed us to focus first on the installation and then on training. Don’t try to do both the same week; everyone and everything will be short-changed if you do. We converted our conference room into a makeshift training room where our key management people spent a week with the trainer going through supervisor instruction. We were careful to ensure that this training time was uninterrupted; making sure all of our staff knew that those in training were not to be disturbed.
Determine all system settings and options: One of the key things we did during supervisor training was to discuss the pros and cons of each system setting and option. Although the decision to have a new system initially work like the old system had made many of these determinations self-evident, there were other preferences and options needing to be resolved. With our trainer’s guidance our management team discussed, agreed on, and programmed all of these selections.
Build a “default” account: While some of these decisions that our team made were system-wide options, other selections needed to be programmed for each account that we would be using. We entered all of these options into a “default” account. This account provided a template on which all future accounts were built.
Build an example of each feature: Next we programmed a series of demo/test accounts. Each feature which we thought we might use was set-up and configured in a working account. This accomplished several things. First, we had a pattern to copy or look at each time we wished to use that particular feature. Next, it was an easy place to go to test the feature or observe exactly how it behaved. Lastly, it would serve as a training account for instructing our staff and for them to use for practicing. Features and services to be included in this step were fax and email delivery, alpha paging, digital paging, voice announcements, remote printing, voice mail, voice mail check-in, manual check-in, auto-patching, Web pop, auto ANI, etc. In addition to testing each of these features, we took great strides to thoroughly document them. These efforts would prove to be an invaluable resource in the months ahead.
Copy the default account to each account you will be using: This established the basic framework for each account and saved a great deal of manual programming and option setting–over three dozen separate entries per account. Teen-pagers adept at computer games, are an incredible asset in projects like these.
Make the changes for options that each account needs: Next, we programmed alpha paging, fax, and email delivery, activated voice mail as needed, and recorded the auto-answer and greetings, etc. Export from the old system and import into the new: To save tedious and time-consuming manual data-entry, we transferred the key elements of our programming from the old system to the new system. This included the answer phrases, account information, message templates, and client directories. Fine-tune the data: It is short-sighted to assume that all of the imported information will appear exactly how you want it. Although you can fine-tune it endlessly, we did allocate some time to this project in order to handle all of the significant adjustments that our staff needed in place prior to the cut.
Conduct TSR training: With data in the system, it was time to have our trainer return for TSR training. Our goal was to have our vendor’s trainer “train the trainers.” This, along with getting the management team up to speed on the new system’s agent functions, were our primary goals for this phase. We did get our training to squeeze in some mini-training sessions with some other TSRs who were influential, change-resistant, or in need of special attention. This is grueling for your trainer, so make sure to take good care of them!
Develop a self-paced training guide for the remaining TSRs: With our trainers and management team trained, we developed a series of self-paced training exercises using our example/demo accounts (i.e. access this account, dial this number, page this person, etc). For some TSRs, this was all they needed to learn and master the system; for most it gave them a good system overview and introduction; for a few it accomplished very little. In any event it helped all TSRs to move closer to the next step. Some TSRs will spend very little time on this step, others will want to invest much more; therefore, grant your TSRs the flexibility they need to use this tool as little or as often as they feel is necessary.
Train the other TSRs: Once our TSRs had gone through the self-paced training program, we scheduled them for two to three hour training sessions in our makeshift training room. This gave us a great time of interaction and mutual education. Each group discovered different procedures and better ways of doing things. In fact, we discovered so much during these sessions, that we brought the initial groups back for more training to show them the new items we had discovered.
Have the TSRs Practice, Practice, Practice, and Practice Some More: At this time, we set up a couple of stations in our operations room. TSRs were scheduled for short practice sessions on the new system. They could also work on these stations during slow times. Again, some TSRs put in a great deal of time doing this and were completely ready for the cut. Others opted to put in minimal practice time and decided to learn when they had to–and not before! Also, we encouraged our TSRs to work in pairs, helping each other out as needed; this was a most beneficial approach.
Peter DeHaan PhD is the publisher and editor-in-chief of Connections Magazine and a passionate wordsmith. Connect with him on his personal blogs, social media sites, and newsletter, all accessible from peterdehaan.com.
See Connections Magazine’s November/December issue for Part II of this article entitled, “Conversion Part II–Cutting Over to the New System.”
[From Connection Magazine – September 2000]