Guidelines for a Pain-Free Technology Deployment

You have just survived the contract engagement process with your vendor. Sometimes that process can takes months to complete. Now you are ready to jump right into the meat of the project and immediately use your new software… but wait, there’s more—that pesky implementation!

The implementation process doesn’t have to be painful if you take the correct steps to prepare—and have selected the correct vendor(s).

 Be Really Prepared

When I was growing up, my mother bought a book called, French in 10 Minutes a Day. The very first lesson was about the seven key words, or phrases, for any language: Who, What, When, Where, Why, How and How Much. While this lesson was intended for a spoken language, it aptly applies to the deployment of a new development project.

When deploying a new technology for your contact center, your vendor can answer the questions of “How?” and “How Much?” In order for the development to be successful, your team will need to answer the other five questions from the technical perspective prior to the start of work.

 WHO?

Who are the correct internal parties to be involved? Gathering the correct team up front and establishing a clear leader will ensure that communication is accurate and effective. The correct stakeholders will also keep the project moving faster with a higher degree of accuracy. Oftentimes, organizations deploying new technology struggle because internal parties are compartmentalized. Appoint a project champion who has temporary authority over the resources of the multiple departments involved. This champion will be able to cut through red tape and make the project both successful and cost efficient.

 WHAT?

What are the systems with which your telephony platform will need to communicate? Does your team have accurate and complete documentation? Your vendor won’t be able to easily determine how to interface with your current systems if your documentation is non- existent or out-of-date. What specific data will need to be utilized? Use this time to ensure that your middleware applications are efficient. If your IVR or ACD servers only need five pieces of information, don’t allow the applications to transmit an entire contact’s account history. This will help you to increase efficiency and stability, to reduce potential complexities, and—depending on the information—to stay closer to compliance standards.

 WHEN?

At which points will your telephony platform need to integrate with your systems? Depending on your feature set, the timing of operations may be critical. Do you need to obtain data from a database or CRM prior to presenting the interaction to an agent?

 WHERE?

Where is a key consideration that is often overlooked in deployment. Where is data housed? Where is the system documentation? Where are your customers calling from? Where will custom applications and software be deployed?

 WHY?

Why deploy new software, features and tools? What will be the advantage that those features provide?

 Define Your Goals

Knowing your goals is essential to a successful deployment and project readiness, but how do you accurately define them?

It is absolutely essential that key technical goals are not overcomplicated, especially when it comes to the technical design. Define your mission statement and validate every decision made by whether it furthers that mission. It is important that your goals and project mission statement aren’t enforced solely against the technology; rather, they should include both the business and technology requirements of the project. Remember, a new implementation or product upgrade is an opportunity to review and revise almost all aspects of your contact center.

While the primary focus of a new implementation mainly affects the technology that your contact center utilizes, consider how each of your decisions, from both an executive and technical level, will impact your current policies and procedures.

Often, poor decisions are made to achieve goals through a complicated and less efficient solution. A goal of “high-quality service” sounds good, but how is it measured? Many times, contact centers focus on the service level objective as the desired statistic, which isn’t in-andof-itself a poor decision. However, if your contact center has no hope of achieving that target service level with current staffing, budget and other factors, the technical team looks for other options, such as disconnecting the calls prior to missing the service level target. Technically, you are meeting your defined goal; however, everyone knows you are blatantly hanging up on callers, which leaves the callers with a negative service experience.

 Start Simple

Leonardo da Vinci once said that “Simplicity is the ultimate sophistication.” In a world where new versions, new features and shiny graphics are the rage, sometimes remembering the key needs of your customers and meeting those needs well is the best approach. From the technical side, consider what your customers can perceive the most: auto-attendant, the IVR and wait time.

Your industry and your customers are rarely the same today as they were when you deployed your current telephony platform and IVR. Why would you migrate your current logic? Don’t simply repeat your old designs and features in your new technology; start fresh. Determine the key needs of your customers and build those specific feature sets.

• Do your customers need to make payments?

• Do your customers desire order information?

• Do your customers expect to control their services over the phone?

One of the most dangerous ways to approach the deployment of a new telephony product is to provide the vendor with the solution to a problem rather than the problem itself. Your vendor(s) will know their respective products far better than you will at the start, and therefore, they are in a far better position to provide a technical solution to a business problem. Often, the solution you would provide is technically complex and will lower the quality of your system deployment. Deployments are far more successful when both teams tackle the problem itself, rather than a predefined solution.

Prepare to Be Integrated

Integrations can offer some of the best features and quality experiences to your customers. To deploy a successful integration, first identify the problem you are trying to solve and the portion of the mission statement to which it relates. An example of a problem-mission statement identification is: “Our goal of ‘round-the-clock service’ drives our company to provide an IVR feature allowing callers to reschedule product deliveries after hours.”

Once the problem has been effectively identified, the next step is to gather the correct resources and make them available. When your vendor(s) begin to design a solution for your defined feature, they will begin to ask questions such as:

• What system controls the deliveries?

• How do you communicate with the system (database integration, web service, mainframe screen scrapes)?

• What information does the system need in the request, and what information will the IVR receive in response?

These are all questions that can be considered and answered prior to the implementation beginning. During the process of gathering this information, use the time as an opportunity to assess your current backend systems. Does the communication stream appear overly complicated? Can the requests and responses to meet the feature’s need be condensed or consolidated? The fewer number of interfaces with which an IVR needs to integrate, the lower the project risk, and inevitably the end customer experience will have a higher level of satisfaction.

Integrations, from an IVR perspective, are not just about the feature sets. Many times the features involve presenting information to the caller. Take care to understand what information the caller is seeking prior to playing data back. Providing the caller with information they already know can annoy them, it doesn’t address their needs, and it adds to your regular costs. As a rule of thumb for data integration and playback, ask yourself if you would use the designed system.

Consider the volume of information presented to the callers. Most callers will only retain a few seconds of information at a high degree of accuracy. Build in features to help the caller during information playback, such as pausing to allow the caller to retrieve pencil and paper.

Change Is Good

In the technology industry, willingness to change and constantly reevaluate is going to be how you differentiate yourself from the competition. It happens in every contact center—over the years, patches and workarounds are put in place to address very specific issues; those could be technical patches or business process patches. Your system design, customizations and offered features should be constantly under review—perhaps not for constant major changes, but always for fine-tuning and improvements.

Why would you buy a new smartphone and expect it to operate the same as your old phone? You should expect new features that will undoubtedly modify your habits. Refusing to change business processes may invalidate the justification of the new software entirely. If you deploy new features and tools, the project is just as much about business process deployment as it is about technological deployments.

Change is often difficult as people and processes become comfortable. It can also be costly if there is retraining required. However, change provides opportunity. If your goal is to change your contact center(s) from a service to a competitive edge, change needs to be constant and deliberate.

Nicholas M. Luthy is Application Development Consultant–Team Lead for Interactive Intelligence, Worldwide Professional Services.

– Reprinted with permission from Contact Center Pipeline, www.contactcenterpipeline.com