Customer Care Framework ( CCF ) and Dynamics CRM 4.0 – What's this all about?

As a Microsoft Technical Specialist focusing on customer care solutions, I often get asked questions regarding how Microsoft Customer Care Framework (CCF) and Microsoft Dynamics CRM work together, when they should be put together, and how they relate to one another. As a result, I thought it would be useful to share some of my insights, knowledge, and a bit of code with you.

Some of this may be background for you; but it’s probably best to start at the beginning.

Getting started

Usually, the first question in any CCF-CRM contact center implementation is, “Why do I need CCF to do this?”  This is a good question and one you should think through carefully.

Microsoft Dynamics CRM, like most CRM implementations, is geared around being the center of your contact center solution. However, more often than not, your contact center staff needs to work with more than one application, launching several applications on their desktop at once, learning how to use them, and managing credentials across them. This common situation can get even more complicated when you want to use information provided by your computer telephony interaction (CTI) channel (like a telephone number or account number picked up by your interactive voice response [IVR] system) in more than one of the applications.

The Microsoft Customer Care Framework was initially developed by Microsoft Consulting Services to address exactly these challenges. CCF was productized in 2005 and has continued to be enhanced to further address these challenges across industries. Here are some of the features in CCF that aid in handling these challenges:

• CCF helps manage your interaction channels (including voice, e-mail, chat, and manual search) so they can provide information to any application CCF is currently hosting.
• CCF provides a search system that can span applications hosted in CCF or back-office applications exposed through services, databases, or other access technologies. The result of the search can then be provided to all applications in the CCF desktop.
• CCF enables you to manage what applications are displayed at any given time, which can be further influenced by a task or workflow-driven process. That means your staff will only see those applications or bits of applications that are required for a given task.
• CCF provides a single sign-on (SSO) system credential store to access and manage user credentials and inject those credentials right into applications. It can also support token-based authentication and other forms of sign-on.
• CCF enables you to create custom controls that can render data from service calls or applications running in the CCF desktop. For example, you can create a custom control to render a summary view of the customer or person you are working with and set this view as the first page when a customer record is opened.
• CCF enables you to automate common tasks across applications. For example, through the CCF user interface you can automate part of your ticketing process to record your contact with one ticket and create a separate ticket in another system to record the actual issue.

This list of examples illustrates why CCF makes sense when you have several applications and processes that your contact center needs to handle.

Microsoft Customer Care Framework 2009 has three major components

• Integrated Agent Desktop (IAD) smart client system
• Multichannel Engine
• Distributed Connectivity Services

The first two components have dependencies on the CCF Server while the third has dependencies on the Distributed Connectivity Services (DCS) Server; all three components also have dependencies on Microsoft SQL Server.  For the purposes of this post, I will focus on the Integrated Agent Desktop component of CCF.

The Integrated Agent Desktop is designed to provide a composite application desktop supporting CCF controls (called a Hosted Control), Web applications, and legacy application support (which in this case means the Win32 applications and Java). It also allows the applications to exchange data and to use a central automation or workflow. Furthermore, it acts as an aggregation point for channels (meaning any form of contact whether CTI, chat, e-mail, or a person walking up to the counter) that are used to create sessions in CCF. For a more in-depth look at IAD, read though the CCF docs at https://msdn.microsoft.com/en-us/library/aa306213.aspx on AIF.

For more in-depth information on CCF, go to: www.microsoft.com/ccf

Microsoft Dynamics CRM 4 provides features focused through several different modules, those being:

• Service — customer care/ticketing and resource management
• Sales — sales force tools and solutions
• Marketing — campaigns and marketing management

For more in-depth information on Microsoft Dynamics CRM, go to: www.microsoft.com/crm

It’s important to understand that Microsoft Dynamics CRM is not only a CRM solution. It is really a line-of-business application platform that happens to ship with a fully-featured CRM solution built on top of it. This platform is known publicly as XRM. The CRM application user interface you see when you pull up a Microsoft Dynamics CRM Web site is a Microsoft .NET Web application built on top of XRM. However, for this blog post, I will refer to the overall system as CRM.

Why is that important?

It’s important because everything Microsoft Dynamics CRM does that affects data, including running workflows, importing, exporting, creating, or deleting, is actually a command to the underlying C/XRM API. This is key to creating a successful CCF-CRM integration, as you will find that some things are far simpler and faster to do using the underlying API than using the actual CRM UI.

This is really where the power of CCF and CRM come together. CCF is a smart client with the full power of .NET available to it, predesigned to support a composite application environment and a Windows Workflow-based system that allows for cross-application user interface automation. CRM provides the business engine and the base behaviors to make your solution incredibly powerful. With CCF you can use CRM to augment existing application features, or even use existing applications to augment the CRM feature set. Or you can base your complete solution around CRM and use CCF as the channel management engine and automate the CRM UI or data layer. At the same time you can manage the UI space through CCF to only show things that are necessary to the user.

So let’s take some common scenarios and walk though them

Let’s start with customer identification and handshake in a typical contact center setting. This is the process in which, on initial call, the customer is identified and the identity is confirmed via pass code or information verification.

For our case, let’s assume that the channel that initiates this request is the CTI channel, and that that channel is going to give us the ANI (the number of the caller), the DNIS (the number they called), and some properties that were added along the way by the automated call distributor (ACD). Also, we are going to assume that we have some sort of dialog box for the search interface.

How do we do this in CRM out of the box?

CRM provides a very powerful search tool that allows us to specify all sorts of parameters and filters when searching for a customer. So let’s start with the ANI. To find the customer in CRM we need to search across all the customer’s potential phone fields.

Or we can use the quick search.

Of the two approaches the quick search method is likely the more appropriate method for a contact center agent.

Note: various ACD vendors provide solutions that make customer lookup more direct with CRM. However, those solutions generally work for Microsoft Dynamics CRM only, and no other application on your desktop.

How would we do this same task in CCF?

In CCF we could take two different paths. The first would be to emulate the user behavior as we did above: navigate to the appropriate screen in CRM and push then push the data into it for searching. CCF provides several tools to be able to do this in a fairly straightforward manner. However, given that we are talking to CRM, this is really not an efficient way to do it. While CCF can do the work faster than the user, we still need to wait for the screens, acquire them, automate them, and then wait for the search to finish.

In a customer care desktop, the customer’s information keys (the telephone number, account number, or some similar combination of identifiers) are usually identified by the business ahead of time. For example, if the majority of our calls are existing customers that will identify themselves by, in order of precedence, an account ID (from the IVR), a phone number, an e-mail address, and finally a name, we can build a specialized UI that initially uses targeted searches for this information and then bubbles up to the CRM Advanced Search features if the user is not found.

It may make more sense to build this targeted search as a repeatable process inside CCF, accessing the C/XRM API directly. We can take advantage of knowing in advance where the data is inside the CRM data store and thus access it more quickly. The benefit is that the information retrieved by CRM in the initial lookup will be made available to all hosted applications and components inside CCF. The catch is that it does require a bit more up-front work to set up a CRM screen.

In our case the search dialog box looks like this:

And when we select the customer, his information appears in this detailed view:

It looks different then CRM, and all that CRM data is actually available to other the applications, visible and hidden, that are in the desktop.

I am going to cover the core of CCF / CRM interaction over the next series of posts. 
I will cover:

• Customer Lookup Provider
• Customer Lookup UI and Creating a Session in CCF
• Displaying CRM Data using the CRM UI
• Creating a augment for CCF that will allow you to notes to CRM
• Creating a Ticket In CRM from CCF.

So, In the next post, I will explain how use the Customer Provider subsystem  in CCF to build a Dynamics CRM Customer Lookup provider.