Your Agents are Not Superheroes! Increase Efficiency by Connecting Data Silos

I am sure you’ve come across several resources that talked about digital channels now dominating over traditional ones.

Even though your contact center might still be in the process of deploying or optimizing these channels, customers don’t care. They want their issue addressed now, and they expect you to know everything about their journey, no matter what communication channel they use.

These new demands add a lot of pressure into what is already a hectic agent experience. Now agents need to know all about the customer’s journey, which means all interactions across multiple channels, as soon as the interaction comes in. This is a tough thing to do if systems and data are siloed.

Agent efficiency in the world of multichannel

Most agents are dealing with several disconnected systems, such as CRM, siloed voice and digital systems, and knowledge repositories, in an attempt to access customer interaction data. They need to know the history of what has been done and communicated to this customer throughout multiple channels. Finding, reading, assimilating and using information within a call or chat is very difficult and is rarely done seamlessly.

On top of having to do it efficiently, agents need to make sure they don’t deliver conflicting messages. As the hosts in a Westworld storyline might mistakenly say: “I’m only human”. Keep in mind – even if you really want your agents to be superheroes, they just aren’t.

The longer the agents look for information, the longer it takes to address customer needs, which results in agent and customer frustrations. Asking them to repeat information already provided elsewhere only adds to customer dissatisfaction.

It’s about costs too. On average, 15% of agent time is spent shifting between systems and applications. Extrapolating that over the course of a full year means significant cost to your business. Can you afford to let that continue?

Accessing customer data through one platform

Top contact center performers understand the importance of reducing the agent’s struggle, by empowering agents with easy access to all customer data on one platform.

This is primarily a technology struggle that can be addressed with unified agent technology. When telephony and other channels are integrated into CRM for omnichannel capabilities, agents can pull customer data and complete work without opening another window.

If an agent can quickly see that a customer has already reached out about a certain request via a different channel, this customer doesn’t have to repeat everything all over again, while the agent can go ahead and complete the task.

By seeing customer purchase history, agents get an opportunity to cross-sell or up-sell, or ask for feedback on product satisfaction and try to improve their experience.

From implementing projects for our clients, we saw a strong need to enable agents with such integration. So, we built a softphone capable of integrating multiple systems in a seamless way. It lets contact center professionals leverage the value of CRM, by making it the focus of their agent interactions as well as minimizing the need to leave the system to accomplish tasks.

When businesses discover a need for connecting CRM with a contact center platform, some of them start building a custom solution. A pre-built, flexible API-based integration saves a lot of time and money, compared to custom development.

Ultimately, the key to a great customer experience lies with a team of successful agents. Successful agents depend on merging of technology with people and processes, combined with training, and molded into a complete solution.

 

5 Questions to Think About When Planning System Integration

System integration planning is the process of incorporating smaller sub-systems into one larger system to ensure they all work together. Integration is a cornerstone of today’s enterprise environments with their multitude of enterprise resource planning (ERP) systems.

The power of those software applications does not lie only in the functionality that they provide themselves, but in their ability to communicate with one another, in order to make data flow seamlessly through the environment. This improves processes and makes a company more efficient as a whole.

When thinking of integration, web services standards such as SOAP and REST come to mind. Those are meant to simplify the integration with the large number of support tools that are built around them.

Unfortunately, the tools themselves are not the solution to your integration problems, but only the means to a faster implementation. The real solution is proper system integration planning and design, which need to be based on the right criteria. And that is not always the case in a project.

So, what are the best methods for the design when integrating two systems? Well, there are a number of questions that need to be answered in the planning stage.

Let’s go through these 5 key questions:

1. What is the data that the target system requires to complete the integration task?

Identifying the target data is an important first step. It defines what objects or tables need to be accessed, and the rules the data needs to comply to. Typically, the target data model drives the design of a custom integration point, should one be required.

2. Where is the data required by the target system located in the source system, and what transformations are needed?

Common examples for data types that need to be transformed are numbers and dates. For example, date formats and time zones may be different between the systems and have to be converted.

3. What is considered a transaction within the integration task and are there any dependencies between the transactions?

A transaction is an atomic unit of work. It only changes the state of the target system if the data was successfully transferred and processed.

If any failure occurs, whether it is during the transport or processing (i.e. validation), it must be ensured that the target system remains unchanged. For example, if a transaction creates multiple records in the target system (i.e. an account and a contact, and the account was successfully created but the contact failed the validation), it must be ensured that the account record is removed again. This way the target system has the same state at the end of the transaction as when it started.

4. How will you connect to the target system (domain name, IP, etc.) and what security constraints apply (certificates, credentials, etc.)?

Connectivity and security constraints should be identified and verified early on in the project. As those can often be reasons for a project to be delayed or even fail altogether. The reasons are manifold like: missing firewall rules, required certificates, setup of new security roles and credentials, protocol incompatibilities between source and target system – just to name a few.

From a technical perspective, most of those issues can be resolved. But it is often the processes or additional constraints that are only identified during the validation, which add more risk and effort to the system integration project.

For example, the target or source system may need to be patched up before they can communicate with one another. On the other hand, the networking team may need to open up the firewall and create new domain name (DNS) entries for the connection to be established. These are typically not very complex technical problems, but depending on the size of the company, they may require approvals and involvement of other groups requiring additional time.

In some cases, changes such as patching a system may introduce conflicts to other parts of the organization, which may make the integration much more difficult or even impossible.

 5. What interface options do you have available (REST, SOAP, Custom, etc.)?

The interface options have an impact on the tools and implementation design. This is because they help determine whether the solution must be entirely custom or whether productized solutions are an effective system integration method.

Creating the right design may not always include the path of the simplest or most straightforward solution.

The Influence of Transactional Requirements on the System Integration Process

To demonstrate the impact of transactional requirements on an integration design, let’s look at the example of an order submission from a Customer Relationship Management (CRM) system to an order management system (OMS). Before the order can be submitted, the system needs to ensure that an account exists since the order must be linked to it. If it does not exist, let’s assume the requirement is to create one as part of the integration as well. The account should only be created for a successful order submission, but not if the order submission fails.

The OMS provides a standard SOAP interface that allows for the typical data operations (CRUD – created, updated, delete) on the entities, such as account and order. It also provides the ability to create custom web service endpoints exposed through the same SOAP interface.

Now, choosing the standard SOAP interface has the advantage that no custom development is needed inside the OMS. The CRM can first create the account using the account interface and then create the order through the order interface. However, while this seems like a desirable approach for the implementation, there are disadvantages that need to be considered.

Since the account and order interface are separated by different endpoints, it requires two independent SOAP requests to submit the order. This means that the risk of a communication channel causing an error doubles. It also means that it requires an additional request to delete the account if the order submission fails to fulfill the transactional requirement for accounts to only be created with a successful order. That deletion request itself has the risk of failure, and that would leave the OMS in an invalid state, because the account exists, but the order does not.

Better Integration Planning

To address all those issues mentioned above, a custom endpoint could be created in the OMS that would consume the data for the account and order in a single request. The logic processing the request would have the ability to validate all the transmitted data for the account and order creation before even attempting to persist the information in the database. And it would be able to handle the cleanup of the account should the order entry fail.

On top of that, only a single request would be made from the CRM, which means less overhead, less risk of failure, and the overall integration process is completed faster than if using the multiple requests through the standard interface.

This is just one example. Of course, even though there are many reasons to consider custom endpoint in the given case, it does not mean that it is always an option to go down that path. Using the standard interface is obviously a feasible option as well, but it comes with increased risk and complexity, and that needs to be understood and included in the project planning.

Every system integration comes with its own challenges. Answering the questions listed above will help to solve those challenges the right way. In addition, if the right validations are done upfront to identify and address those risk factors around connectivity and security, it will just be a matter of time until the two systems are integrated with one another, boosting the productivity of your company.

Need help with your system integration plan?

Our enthusiastic and highly experienced team can assist with your software integration planning and contact center integration needs.  Let us know how we can help!