Tag Archives: CRM integration

Building a Fully-Integrated Contact Center with Amazon Connect and Salesforce

When AWS launched the Amazon Connect cloud-based contact center service, our breath was taken away by the power and the flexibility – making us quickly become one of the first APN partners and take part in creating new add-on functionality and services.

Having experience building customer engagement functionality in Salesforce that only supports digital channels, our team realized that Amazon Connect and its voice-based channel was a natural fit. So, this was the obvious first place for Aria to invest in to provide customers with a fully-integrated contact center.

Bridging the silos with pre-built components

No one wants to have their technology run in silos. By integrating both cloud-based solutions, organizations can:

  • Improve customer experiences by properly managing customer interactions across voice and digital channels
  • Improve employee productivity by automating tasks and reducing the number of screens they must use to handle customer interactions
  • Gain full visibility of how well the contact center is meeting customer demand

To make this happen fast with less effort and lower risk, Aria built two options:

1.  Free toolkit to try things out on your own

This is an advanced adapter that’s using Salesforce’s Open CTI, which brings Amazon’s Contact Control Panel right into Salesforce. The toolkit offers out-of-the-box integration between Salesforce and Amazon Connect, which is built on industry best practices. Agents can receive and control the calls and see customer information right within Salesforce – the same place where they handle digital channels.

As part of this integration, the toolkit migrates Amazon Connect call data into Salesforce, for all interaction data to reside in one place. Providing contact center managers with a clear view of their operations across all channels.

Other AWS applications that are often used in the contact center, such as Lex bot data, and transcriptions with Amazon Transcribe, are also made available right within Salesforce.

Not only does it provide some great features out-of-the-box, it’s also meant to be customizable and extensible, by giving you the rights to copy and modify almost all pieces of code to adjust the functionality to your own needs.

2.  More advanced, supported integration through Legato

Another option to consider is Aria’s Legato, which includes all the same functionality as the free toolkit plus a customizable softphone. It is a packaged and fully supported product that includes automatic upgrades and will soon be available on the Salesforce AppExchange.

This option lets organizations skip the internal development stage and go straight to a supported product – should that be the desired path.

Making your customer engagement center even more advanced

Aria has over 20 years of contact center experience and a depth of knowledge on how everything interconnects as a single solution.

If you want to add more functionality to improve customer and employee engagement in an efficient manner, here are some service options:

  • Setup of Amazon Connect
  • Voice and digital bots with Lex
  • Integration of industry-leading CRM and WFM tools
  • Advanced functionality provided by Amazon Connect partners, such as advanced sentiment analysis, dynamic phone numbers, fraud detection, and in-session SMS

To learn more about these options and what’s possible with Amazon Connect contact us to talk to our experts!

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!