CCaaS and CRM: The Devil’s in the Detail

What should a CRM + CCaaS integration achieve?

One of the things you should consider is why you want to integrate in the first place. There are some basic use cases such as popping a customer record within the CRM at the point of interaction. This can be based on matching a telephone number, email address or social media handle. It is an old concept but presenting information within CRM automatically to the agent is preferable to the agent having to manually search for it. The more intermediate use case might be to apply different routing strategies based on data held in the CRM. For example, a customer whose account is in payment arrears might bypass the standard call flow and be routed straight to the collections team, or as part of our vulnerability framework, we might want to flag our vulnerable customers in the CRM so that when they contact us, their call is prioritised.

Increasingly, we are seeing examples of more advanced use cases for CRM and CCaaS integration. That might be the ability to trigger an interaction based on an event within the CRM such as an outbound call triggered by a web enquiry. As part of any project that addresses this kind of integration, the specific use cases should be set out clearly and we should never assume that an out-of-the-box connector caters for all scenarios.

Which application do agents work in?

Bringing the CRM and CCaaS platforms together through integration raises the question of screen real estate. Are agents principally working within the CRM, or is there an opportunity to bring CRM data into the CCaaS agent desktop? If your organisation uses a CRM to drive all its web self-service content, its virtual assistant and route and manage digital channel interactions, it might be logical to 'plug in' a CCaaS platform to manage voice, coaching, quality etc. Many CCaaS vendors can snap into the Salesforce.com or Dynamics365 user interface to avoid running a separate application on the desktop.

This approach, however, can quite often be compromised. Using separate platforms to route different channels can lead to quirks in routing, reporting and limits around integration with workforce optimisation tools. The alternative is to flip this around. Most CCaaS vendors have a UI that allows the presentation of information from a 3^rd party CRM. A key factor in the decision is often the ownership of the platform, i.e., for many organisations, the CRM remains the responsibility of the IT or Product teams, whereas we are seeing CCaaS commonly be managed, administered, and operated by the business. That brings us on to another important consideration… 

Who owns the platform?

This is where the culture of your business can have a significant bearing on how you design your customer service environment, particularly regarding the CRM and CCaaS relationship. Many will identify with one of these scenarios:

"Our IT team own the CRM and it's a slow and painful process trying to get changes made to benefit the customer service function."

If the above scenario sounds like you, there is a real advantage of shifting more of the emphasis towards CCaaS to help enable your improvement initiatives. More and more commonly, CCaaS platforms are faster to implement, offer greater control for users to make changes and are developed for customer-facing teams. If you have greater control, then A/B testing and impact assessing innovative ideas and initiatives is infinitely faster. As a result, you can work in a much more responsive, agile way and that means you will get to your destination sooner.

"We are a technology-led business and value development in order to differentiate in our market."

Tech companies may develop internally and might be less likely to use an off-the-shelf CRM platform. Here you might have in-house developed systems, centralised customer data and more agile ways of working across the business. This is where an out-of-the-box connector will not meet your needs and instead you need a CCaaS vendor with a flexible API (Application Programme Interfaces) library and an open approach to integration. It might be more typical here for the Product team to own the contact centre tooling.

Mind the Technical Knowledge Gap!

So, you have your use cases for integration clearly mapped out, the CCaaS vendor has a connector into your CRM tool… that means you are all set!... Well, maybe not. Inevitably the CRM will have been configured with specific workflow, business rules and logic. To trigger the right behaviour from the CRM and CCaaS integration, there needs to be input from both sides. One of the pitfalls here can be the knowledge gap between the CCaaS vendor and your CRM experts.

All too commonly buyers are enticed by the simplicity of 'out-of-the-box' connectors and projects can completely run aground when the realisation bites that it is not that simple at all. This is where a keen eye for detail and a collaborative approach is key to success. For example, an inbound call might trigger an action in CRM but exactly how that action is triggered and the specific behaviour on the CRM side is usually outside the remit of the CCaaS vendor. It works the other way round too. If tasks are being routed to the CCaaS solution via an API, it is important for the task to be routed to the right skill or follow the right set of logic.