Harvard takes a long, slow approach to IP call center integration

How do you deploy a centralized IP contact center across 10 different networks? This is the challenge that the telecom department of Harvard University faced in 2001 when undertaking a replacement for its existing system.

Last week, Michael Rowe, manager of systems and applications for Harvard's Telecommunications Department, shared how the university overhauled the call center infrastructure to embrace IP, expand features and keep costs down.

Because of the complexity of the mission and the fact that no commercial call center was designed for such an environment, the contact center platform was installed in two years, but after seven years the project is still a work in progress, Rowe told the Association for Information Communications Technology Professionals in Higher Education, also known as ACUTA.  

No Harvard unit has a call center in the traditional business sense of a roomful of agents trained to handle similar calls. Instead, the centers consist of groups of agents (as few as three but no more than 21) spread around Harvard facilities in Boston and Cambridge, Mass. The goal was to have a single call-distribution device that could handle all of them.

Click to see: Diagram of Harvard's call center

At the outset of the project in 2001, the phone system was centralized, delivered via Verizon Centrex over Primary Rate Interface trunks to 30,000 phones. Call-center features also were provided by Verizon, queuing up everything from help-desk calls to questions about university medical benefits.

When Verizon decided to phase out the service, Harvard went looking for a replacement that could route calls to appropriate extensions as they came in.

Even with the help of a consultant, finding the right product was difficult, Rowe says. After reviewing 16 RFPs, the telecom team chose six finalists to demonstrate their wares. The results were dismal: Only a few managed to get their systems to work in the university environment. The team chose Customer Interaction Center (CIC) from Interactive Intelligence, because it had more flexible administration and allowed for expansion to meet future demand, he says.

Still, CIC wasn't ideal. It required adding Active Directory and Exchange servers to the network. Initially Rowe placed two servers in the Harvard data center where they could back each other up automatically, but the automatic backup never worked smoothly. The servers proved temperamental, failing over at the slightest glitch and always requiring human intervention, he says. "The software worked great, the switchover was the problem. It was not a good solution," he says.

So, when the telecom department moved to a site served by two central offices, Rowe saw it as an opportunity to split up the CIC servers also, sacrificing redundancy but gaining diversity of routing that could keep the university supplied with service if one central office failed, he says.

CIC had other challenges. It was designed to work best when phones are plugged directly into it. Because Harvard phones were on the Centrex network, each had to be treated as a remote extension. That meant bridging incoming calls to the agent extensions, which ate up two PRI channels — one for the incoming call and one for the bridge to the right extension.