Introduction

Most of us have seen or heard of Contact Center infrastructure projects that didn’t quite achieve the goals they set out to. At least not when they were first implemented. There are a lot of ways that this can occur but in my experience what many of these projects have in common is they began the implementation without a thorough solution design and simply ran out of implementation funds long before they ran out of things to implement.

It would be easy to say that the wrong solution or vendors were chosen; or that the vendors were not adequately engaged; or that requirements were not adequately detailed or elaborated upon but I would argue that while any of these can certainly contribute to a solution’s failure to achieve its objectives, more often than not, the root problem is a general lack of effective solution design processes. This article will discuss how Contact Center solution implementation can go off-track and how to avoid letting this to happen in your company and to your solution.

How the Request for Proposal (“RFP”) Can Contribute

Many Contact Center infrastructure and other Customer Experience (“CX”) solution efforts begin with an RFP process whereby the client or their representatives issue an RFP to solicit responses from prospective vendors.  I currently have two different RFP’s from business partners sitting on my desk at this moment. Both are for fairly complex solutions and environments for mid-sized to large enterprises.  One of them is 10-pages long including the cover and table of contents pages while the other is 23 pages (more half the content is a sample of the customer’s desired master services agreement).  We will cover crafting an effective RFP in a different article but I would argue that while the approach of letting the vendors “tell their story to you” in an open format can be very effective in some cases, it is perhaps not the best approach to a solution which will ultimately impact your entire contact center/CX delivery solution.

While an argument can be made that many of the solutions for Contact Center today have very similar capabilities, the reality is that they each deliver those capabilities in very different ways and with varying degrees of ease or complexity once the implementation begins. Further, it’s not like one solution is easy to implement in all cases and others are not.  How easy or hard it is to implement a given solution goes back to what it is that you need the solution to do and more importantly, how you need it to do it.

Even if the RFP is extremely thorough and the vendor’s response to the RFP is exceptional, the content of the RFP (the questions) and the vendors responses are focused on what the vendor’s solution can do; not specifically how they do it in your environment.  The last two items are particularly important.

Worse still, the RFP response team is handled by sales and pre-sales teams and although they may be supported by architects or others during the RFP response, it is pretty rare that the vendor’s RFP response makes its way to the implementation teams.

The Role of the Typical Solution Sale Lifecycle

Once the solution vendor has been decided upon, the next step is typically the contract negotiation phase. In 99% of cases, this negotiation is between the vendor’s sales and legal teams and the client’s legal and procurement teams.  In most cases, and as would be expected, the company acquiring the solution will negotiate pretty hard with the selected vendor. The desire being to get the solution at the lowest cost possible.

The selected vendor essentially has three levers to pull when it comes to pricing out the solution;

• License costs (per seat, per site, per server, etc.)
• Components included in the solution (often there will be enhancements or add-ons for the solution that are recommended in the RFP process to address specific functionality more easily)
• Implementation costs (e.g. Professional services fees)

License Costs

Quite often vendors will offer a “standard” discount based on the number of seats, their relationship with the purchasing company, or other factors.  In most cases, the vendor may have some flexibility on license discounts but it is worth noting that at some point, and if the vendor is pushed to discount too much, they will attempt to make this up in other areas (such as implementation costs or component costs).  In other words, just as the customer has an imperative to obtain the solution as inexpensively as possible, the vendor has an imperative to ensure that the business is profitable to them.  While it is easy to say as a customer that this is the vendor’s problem (which it is), it is worth noting that as the negotiation continues, someone from the client’s business and technical teams needs to be there asking the question “how will this impact our implementation”.

Component Costs

Components that may be added to the solution to enhance functionality are typically acquired through either a per-seat bump in license costs, a one-time fee, and/or a one-time implementation costs (to enable and configure the component).  To the extent that these are included in a given solution, the vendor will have assumed the use of that component in their response to the RFP. If the component is subsequently dropped during contract negotiations, there will almost certainly be impacts to the solution’s capabilities. In some cases, there will be workarounds to enable the required functionality in some other way but in those cases, the implementation costs and solution complexity (in most cases) is going to go up, not down. In other words, you are stealing from Peter to pay Paul.   Again, in these cases, someone from the customer’s business and technical teams needs to be involved in the discussion to ask the all-important question “how will this impact our implementation”.

Implementation Fees

There is no question that there is a tendency to over-estimate or “cushion” implementation costs in an effort to give the solution provider or implementation partner room for the unknown and unexpected. Anyone that has been involved in a Contact Center or other CX solution implementation knows that the unknown and unexpected will absolutely occur during any implementation. While a nimble implementation team can often find ways to work around these issues, there does come a point at which “nice-to-have” features and functionality (e.g. those neat features the customer planned on) begin to fall off the list of things that can be accomplished.  These are followed by core features that are/were needed to support the business if more unknown and unexpected events begin to occur (hint: they will and do).

As with other costs, when it comes to negotiating implementation costs down, someone needs to be asking how exactly how this will impact the implementation and the desired outcomes.

From Selection to Implementation

For the balance of this article, let’s assume that everything has gone exactly to plan, meaning;

 

• The company issued a thorough RFP that provides rich insight into what functionality they needed and how that functionality would support the business
• The selected vendor responded thoroughly to the RFP with details on how their solution can meet each and every requirement in the RFP
• The vendor negotiations and procurement process went smoothly and all parties feel confident that the solution can and will be implemented to meet the customer’s needs and expectations.

In this case, the next step is often to engage the vendor and/or integration partner and begin the implementation process.  Once the implementation begins, the vendor and/or implementation partner will generally begin the process of translating the customer’s requirements to an actual implementation but it is important to note that in almost all cases, the people involved in this process are not  the same ones that were involved in the project up to this point. Whether they were or were not, what is universally true is the clock has started on the implementation and every hour used to translate requirements to actual functionality in the system takes away from the time to implement the solution. If there is not a specific phase in the implementation to complete a detailed design prior to beginning implementation, the people making the decision about how to implement some piece of functionality are generally the members of the implementation team (e.g. the developers or systems admins/developers) and these staff are operating against a schedule. While they certainly want the solution to be successful, the decisions they make are often driven by the need to make the solution operate in a certain way and they may not always have the time to consider implications further downstream, like reporting or other critical features.

If it happens that the implementation budget was reduced during contract negotiations, this situation and the impact it has on the implementation team is made all the worse.

The important take away here is that in order to ensure the success of a solution implementation, time must be allocated to create a detailed, vendor/solution-specific design before the implementation begins.  Further, the implementation team should be allowed to review and comment on the design before it is approved to ensure that it can be implemented as-designed and within the budget allocated during the actual implementation phase.  In many cases, if the solution design is completed properly, implementation times can be substantially decreased.

What Should an Effective Solution Design Include?

There are a number of elements that should be included in an effective solution design. Some of these may have been created in other phases of the project in the lead-up to the vendor selection but should be included and in most cases elaborated upon in the solution design document.

Background Material

Some of the materials that would typically be included in the Background section of the design document would include things like solution business and technical requirements, use cases, and information pertaining to the customer’s enterprise voice and data network and services.  These items combined, whether they already exist and simply need to be inserted into the document, or if they are yet to be developed, provide the implementation team with a thorough understanding of the environment in which the solution will operate along with an understanding of how and why the client needs the solution to operate in a specific way.

Requirements and Requirements Analysis

Often, the client will have provided some level of requirements analysis or specification during the RFP phase in order to allow the vendor(s) to better understand some of the specific needs the client has and how these pertain to the solution. The question, of course, is how thorough these requirements are documented and to what degree they have been elaborated upon to trace them back to specific features of the selected vendor solution or to other parts of the solution which may be impacted in some way.

As a general rule, the more specific you can be with requirements analysis and elaboration, the more likely it is that your solution implementation will go to plan.

Use Case Analysis

Use case analysis is perhaps one of the most dreaded and [therefore] most under-utilized components of effective solution design.  Many people consider these to be too much trouble to undertake given the sheer number of use cases that need to be considered for most Contact Center or other CX solutions. In an ideal world, the use cases would be exhaustive but obviously, this can be extremely time-consuming and costly to develop.  Wherever the option exists to create them, however, it should be seized upon.

In those cases where exhaustive use case analysis is not an option, effort should still be placed on identifying and elaborating on “key” use cases that represent a subset of the functionality required in the solution that are considered most critical to the success of the solution overall.  These would include things like handling of inbound interactions (e.g. inbound call or chat treatment and routing), handling of interactions across or between different channels, agent interaction handling (what happens when an interaction arrives at an agent’s desktop).  In all cases, the use case should include not only how the interaction or activity would be handled but what data, events or decisions related to the processing of the interaction should be reported on.  This is particularly true in cases where an IVR is used for processing of inbound calls (or proactive/agent-less outbound) or where chatbots or other features are used to process customer interactions in other channels.

Environmental Information / Drawings

Whether the solution is an on-premise solution or a cloud-based one, it will ultimately be necessary for interactions, data, and of course the user’s communication channel to traverse the company’s internal voice and data network. Specific network configurations and security features can and will impact how the solution is implemented and while the vendors will inevitably ask for this information at some point in the implementation (very early on hopefully), providing environmental information and drawings in advance and in-detail serves to move things along more smoothly.

Infrastructure Design

Quite often when we think about “infrastructure design” the picture that comes to mind is all the servers, routers, interfaces and other hardware components that are required to make a solution work.  In Contact Centers, however, there is another set of infrastructure elements that often go unnoticed until well into the implementation. Unfortunately, it is this other set of infrastructure that has the greatest and most direct impact on the company’s ability to report on operations in the environment.

The infrastructure I am referring to are the “queues”, “skills”, “teams”, “agents”, and other solution elements on and through which interactions are processed and handled.  I put the items in quotes since the names/terms used to define them vary from one system to another.

In the old days (and still today in some solutions), interactions (typically voice calls) entered the environment from a trunk group and were dropped into a queue or vector for servicing.  Based on rules defined for the queue, the interaction might be routed to an IVR for treatment or routed to a servicing group or other target for immediate handling.  This may or may not involve dequeuing the interaction from the initial queue it landed in and sending it to another either before, during or after the interaction is processed initially.  Once the interaction is ready to be delivered to an agent or agent group, the call would be queued for one or more specific skills required to service it and again, based on rules defined would eventually be delivered when a suitably skilled agent becomes available.

At each and every point along the way, we would probably want to be able to report on why the interaction went where it did and how but without careful forethought, being able to achieve this level of reporting is anything but guaranteed.  Most vendors provide IVR reporting for instance but in many cases, how and more importantly how well this works is wholly dependent on how the underlying infrastructure has been designed and implemented.  If this decision is left to the implementation team, they may or may not consider the company’s reporting needs and the company may or may not get the reporting desired as a result. In my personal experience, it’s a generally bad idea to just assume that the developer(s) or systems admin(s) responsible for actually implementing the solution know what you want in reporting.  In most cases, they do not and will not.

Using “Route Maps” to Clearly Define Interaction Handling

A route map is a tool that we often use to define how interactions should be processed in a given environment and includes (at a minimum) the following elements;

• Entry point map – these are typically defined in a spreadsheet and identify all of the ways that interactions can enter the enterprise. Typically these will include maps for each interaction type and will list how each is processed initially. Using a voice channel as an example, the entry point table would include a row for each DID/Toll-free number, its country of origin, purpose (if the number is assigned for a specific purpose such as west region sales for example), DNIS associated with the number, default language, and an entry point name which depending on the system may be the receiving queue, receiving skill or tag that may be used in attached data and tracked with the call.
• Exit point map – like the entry point map, the exit points are typically defined in a spreadsheet and include all of the data and other information required to process an interaction whether it is completed entirely through automation (in an IVR or via a soft-agent/chatbot), or sent to an agent (human) for further servicing. A specific exit point should be listed for every place in the system where the interaction is either completed through automation or transferred to an agent for servicing.  For each exit point the following would typically be defined;
  1. Target Queue (if applicable)
  2. Target Skill / Skill Group
  3. Initial Interaction Priority
  4. Target language
  5. Target metrics like
     • Average speed of answer
     • Service level targets, etc.
  6. Secondary/fail-over targets including secondary skills or other skill changes that may be instituted to get the interaction processed
     • These should be defined in the exit point map for each level of “expansion” explicitly defined to handle the interaction
• Skill maps – A skill map list out all skills defined in the system and the group or groups that those skills are defined for. These should be listed by media/channel type and include any vendor/system-specific definitions for items like automatic priority increases based on time-in-queue or other factors.

Having this information documented in advance of the implementation takes a lot of the guess work out of the process for the implementation team and also serves to provide excellent documentation of the solution post-implementation.  One added, but extemely valuable benefit is that it forces those involved to think carefully about how the infrastructure should be configured to achieve both the interaction handling and reporting performance required.

Interaction Flow Diagrams

Interaction flow diagrams are essentially Visio™ or other diagrams (check out LucidCharts if you’re tired of chasing Visio versions) that depict the flow of an interaction through the environment.  Typically these would be created for each major interaction type at a minimum and would depict treatment (messaging, routing, key decision points) encountered as the interaction flows through the environment and helps to shed light on key decision points and messaging encountered along the way. The level of detail should be sufficient to give the business team(s) clear guidance on what the customer experience will be and, equally important, what data or other information would be used to move to the next step and of course, report on it downstream.

In our approach, we use two distinct types of diagrams which are described below.

High-Level Interaction Flow Diagrams

High-level flow diagrams are visual depictions of how interactions are handled in the environment. They should be defined for each distinct channel type used (since the interactions generally vary by channel) and for different parts of the organization to the extent that processing varies based on where the interaction occurs (for what function in the organization). For example, if you have customer service that handles both inbound calls and chat requests, you would be well-served to define flow diagrams for both.

Implementation Diagrams

Implementation diagrams, in essence, take the high-level interaction flow diagrams down to a level of detail that supports the implementation team directly.  In our use of them, we generally create one implementation diagram for each high-level flow. The difference is that in the implementation diagram, we insert more detail to specifically call out exit and entry points, attached data used or captured (if applicable), and other information that may be needed to support either operations or reporting.  You could, of course, put all this into the high-level flow diagrams but in my experience, this quickly becomes both messy and overwhelming since each diagram type is targeting a different audience.

High-level interaction flows generally target the business and user communities by allowing them to “see” the flow and have sufficient detail to review and approve it.  These may be useful to the implementation team as additional information to guide their work but on their own, lack the necessary detail to ensure the implementation is done as required to meet everyone’s needs and requirements.

Implementation diagrams are designed to support the implementation teams directly and are specifically written using terms and other definitions that are unique to that vendor’s implementation and/or system in order to avoid confusion.

Systems Integration Documentation

It’s pretty rare these days to find a contact center or CX solution that is operating in a vacuum, in most cases, these systems interface directly with servicing applications, back-end databases or systems, web services of all descriptions as well as other in-house or online systems that provide a variety of services.  In each of these cases, some form of interface is generally required to enable communications between the two systems and to ensure that the required functionality is enabled correctly.

As a rule of thumb, we recommend including an “interface list” that identifies and describes each external interface required, lists the type of interface it is (e.g. web service/type of WS, API call, custom interface, etc.), the direction (used to request data, used to initiate a function in an external system, bi-directional comms, etc.), and describes its purpose and use.

For each interface in the list, the design documentation should include a detailed description of exactly how the interface is implemented and all data or methods passed.

Summary

We know that all this may seem like a great deal of work. But, the reality is that you don’t have to look very hard to find solutions that failed to meet their original goals or failed to deliver on the customer’s expectations.  Taking the time to follow good design practices will help your organization to ensure that you and your customers really do get the solution you need and expect.  You will be happier, your customers will be happier and in virtually all cases, the vendors involved will appreciate the effort you and your organization are undertaking to ensure the project’s success.

As Albert Einstein said, “If you don’t have time to do it right, when will you have time to do it over”.

As always, it would be our pleasure to help guide you along the way.  To get more information on our services or to contact us go to https://contactscope.com