Breaking down contact center interactions – which system is primary?

With our focus on Contact Centers and all the technologies used to optimize them, one of the common questions Avtex gets relates to which system should be the system of record for incoming interactions.  This is usually meant to delineate whether it is the CRM application or the ACD skills based routing engine that is responsible for carrying that interaction from the customer to the agent who can assist them.

While I’d be overstating the case to say there’s only one answer to this question for all technologies and all scenarios, I’m very comfortable laying out our typical approach to figuring that out.  In our scenario, we’re usually working with the 2 best-of-breed applications to optimize this process – Microsoft Dynamics CRM and Interactive Intelligence Customer Interaction Center.  It doesn’t matter to us whether you use cloud-based or premise-based versions of either product.  Mix and match them as fits your business.  Since both are based on .Net technologies, integrating them is more straightforward than for most others.  Since the CIC platform can route not only pre-defined objects but also generic objects of any kind and CRM can easily hand objects of all kinds off, these 2 platforms are a near-perfect combination for efficient contact center operation.

We typically break the channels supported into 2 categories from a philosophy standpoint :  1) Calls and 2) Everything else.  Let me address each in turn.

1) Calls:  As calls come into a contact center, a common tactic to try to provide a great self-service experience is to have an Interactive Voice Response (IVR) unit that answers first (an IVR is part of the CIC unified platform).  If that is the case, we always try to have that IVR dip into CRM to try to find that caller in the CRM database as soon as it’s possible to identify them (sometimes before it even picks up, but sometimes only after they’ve put in an ID of some kind).  If the caller has a CRM record, we want to use whatever data we have stored in CRM to try to personalize and optimize the experience that caller has interacting with the IVR.  We also want to record that the IVR interaction has happened in CRM as a customer touch-point, hopefully storing whatever branches of the IVR they went through.  If there is no match to a CRM customer record, the IVR will be less personal, but will still be recording all the activity of that interaction and storing it in case the call gets transferred to an agent to assist, to start filling out a new customer record and interaction history for them upon answering.  At this point, regardless of whether there was a CRM match or not, the system handling the details of the interaction is the IVR.

Some calls will need to be passed to an agent for live assistance.  When this occurs, the ACD engine (an ACD engine is part of the CIC unified platform) “decides” who gets that call.  It usually is dependent on a set of routing rules that take many things into consideration, but almost always keys off of at least agent skills and availability.  As the call makes it to an agent, if there is no IVR in place, we have the ACD engine pass in identifying information into a CRM query (at least the phone number of the caller) to try to find a match.  If there is an IVR, we already know if there was a match and we pass in the unique identifier of the customer record to pop, along with anything else we can pop for an agent without them having to type anything (often dynamically surfacing knowledge base articles that are relevant).   We want to always do a screen pop to automate as much of the process as we can.  This screen pop is the system handoff from the ACD engine to the CRM tool, at least until that agent is finished with their part of the interaction.

2) Everything else:  This includes things like e-mails, website submissions, SMS texts, social network posts, chats, video requests, follow-up activities, escalations, outbound dialer campaigns (an outbound dialer is part of the CIC platform), and more.  The philosophy we use for these is to create a record in CRM immediately for these interactions tied to the customer’s CRM record (even if the basic customer record has to be created), capturing as much knowledge as possible in the process to record in CRM without degrading the customer experience.  We then pass the identifier for that record and the appropriate details from CRM into the ACD engine to have it routed optimally to who can best handle it.  This way we can have robust routing rules including the dynamic prioritization of interactions based on importance (could be customer importance or interaction-type importance)  and all the details are already there for the desired screen pop of appropriate customer and interaction information for the agent at hand.  The screen pop occurs and the handoff from CIC to CRM takes place again.  It’s exactly the same agent experience regardless of the channel or activity type they are working with.  Consistency = efficiency and quality.

In the end, we’re doing what’s natural.  We’re letting each application play the role it’s best at.  Each one plays the primary role in the interaction when it’s the best system to do so.  The ACD is the best system for real-time routing.  We leverage that.  The CRM system is the primary database of customer and transaction information for the history and details needed to deliver great experiences.  We leverage that.  We use our knowledge of the platforms’ strengths and the rich tools available to make them “talk” to weave together the ideal solution for each business scenario.

We’d love to help you architect the ideal solution for your contact center too.

Bart

The following two tabs change content below.

Beth Ingebretson

Categories: Contact Center and Customer Engagement.