AI-powered Customer Support Automation for European FinTech Corporation

Project Overview

Our customer is a European FinTech corporation, provider of global digital payment solutions. The company was looking to improve its customer support processes, with the focus on email support, by reducing the cost via AI-powered automation, as well as decreasing response time. We started developing customer support automation solution for them in 2019 and have been working together since then.

Step 1. Discovery and Analysis

Discovery Phase

We started the discovery phase by analyzing customer support emails collected during the three previous months (older ones were automatically deleted per the company’s policy). As a result of categorizing these emails, and analyzing how they were handled by the customer support team, we discovered the following:

• A large chunk of the response time was taken by the first line of support. Around 200 emails were coming into five company’s support inboxes combined, and four company employees were responsible for creating support tickets for these emails in the Salesforce CRM and assigning these tickets to appropriate handlers. The reason for this was that the support inboxes were not specialized, containing emails for various topics, meant to be handled by various specialized support teams, such as technical support, legal support, etc.
• Around 30% of the incoming emails were, one way or another, related to the customers wanting to change their data within the system. Although the process had some legal complications, it could be fully automated if the appropriate UI was provided to the customers, allowing them to enter the data themselves.

Requirements Elicitation

As a result, we have defined these two key requirements for the AI-driven customer support automation system:

1. To automatically recognize and categorize the intents of the incoming customer emails;
2. To allow the automatic fulfillment of the outlined subset of recognized customer requests.

Because not all customer requests could be fulfilled automatically, some of them were just labeled with the correct category and sent to an appropriate customer support agent. For the subset that could be fulfilled, the system had to include an AI chatbot, that would confirm the customer’s intent to change specific data, and UI forms to enter the data. An additional set of requirements included the following points:

• All of the automated decisions had to be logged in the CRM (Salesforce in our particular case).
• The data change couldn’t be applied automatically and always had to be approved by a human agent.
• The chatbot and the UI forms had to also be integrated into the company’s self-service portal, so the email was not the only entry point.
• The client should have been authenticated before submitting a data change request.
• For privacy reasons, the automation system shouldn’t have stored any data, but rely on the CRM and the company’s back-office system instead.

Step 2. Architecting AI-driven Customer Support System

Architecture Overview

Building the CSA solution required integration with several existing software systems, as well as the company’s support portal, which at that moment was under development. The next figure illustrates the interaction between the customer, customer support agents, and the automated customer support software system.

Basically, the customer requests would flow in one of the two ways: via email or the company’s support portal.

Via email:

• The customer sends an email to the support inbox.
• The email is synchronized with the CRM, and the support case is created.
• The case is sent to the Customer Support Automation (CSA) system.
• CSA tries to recognize customer’s intent, after which one of the two things happen:
  • If the intent is not recognized, or is recognized but is not supported by CSA (cannot be automated or not yet implemented) the case is updated with recognition results and is assigned to a human agent. This ends the flow.
  • If the intent is recognized and is supported by CSA, a link to the UI is sent in an email reply to the customer, where the customer can continue with the request fulfillment.
• The customer follows the link to the UI and gets to talk to the chatbot, which confirms the intent, as well as the customer’s identity.
• After that, the customer enters the intended data change and is authenticated via SMS. (As it happens, the company’s customers usually don’t have any kind of user accounts with login and password, but always have their phone numbers in the system). The phone number is retrieved from a company back-office system.
• After the successful authentication, CSA submits customer’s data into the back office, and assigns a human agent to the case, for the data change approval.

Via portal:

• The customer logs in to the portal and starts a conversation with the chatbot, that is integrated into the portal.
• CSA (which the chatbot is a part of), creates a support case for this specific issue.
• Chatbot tries to recognize the customer’s intent, and, if it’s supported, the flow is continued in the same way as the email flow, starting from the #4.

Detailed CSA System Architecture

Since the solution required integration with many external software systems, as well as running computational-heavy AI models, a microservice approach was chosen, as the best fitting one from the start. The detailed architecture of the developed solution is shown in the next figure.

When breaking the system down to the microservices we followed principles of loose coupling and single-purpose. Although the system contained many microservices, all of them can be broken down to these four types:

• Gateway: serves as an entrypoint to the application. Gateway encapsulates the functionality that other microservices provide and exposes that functionality to the external software systems. Gateway is the only type of microservice that is exposed to the outside. In our case, we implemented two gateways: one for the frontend UI applications and one for integration with the Salesforce.
• Reverse proxy: handles all the outbound interaction with the external software systems. Same as the gateway, but in this case, the external software systems are on the other end of it. The reverse proxy is responsible for all of the interactions with its software system, completely “hiding” it from other microservices. Examples: SMS service reverse proxy, Back office reverse proxy.
• Worker: your regular microservice, responsible for a part of business logic that is contained in the application. The worker is a single-purpose microservice that is isolated from the outside world by gateways and reverse proxies. Examples: intent recognition service, chatbot service, email processing service.
• Infrastructure service: the service that has a utility purpose, containing no business logic. Example: scheduler service.

For the communication between microservice we chose a message bus, for two reasons:

• Reliability – messages in the bus will not be lost if one or more services are down.
• Load-balancing – having multiple instances of a single service consuming the same bus provides out-of-the-box load balancing.

AI Workflow

The developed customer support automation system contains two specific Artificial Intelligence microservices – chatbot service and intent recognition service, as illustrated in the scheme below. Intent recognition service is responsible for natural language understanding, with AI models trained specifically to recognize customer support requests. Chatbot service is responsible for handling a conversation with a customer, while also reusing intent recognition service for, well, intent recognition. Both services require binary machine learning model files to run, which are included in the services Docker container on the build stage. This ensures maximum performance of the services not having to download their models from an external source. External storage is used for chatbot conversation state though, to ensure that chatbot service is stateless, and therefore, horizontally scalable.

Architecture Patterns

Here is a list of some architecture patterns that we, as you may already have recognized, used when designing our solution:

• Ambassador: can be used to offload common client connectivity tasks such as monitoring, logging, routing, and security (such as TLS) in a language-agnostic way. In our case, “reverse proxies” implement an ambassador pattern, plus also additionally encapsulating a logic that is specific to their external software system.
• Backends for Frontends: creating separate backend services for different types of clients, this way helping keep each microservice simple, by separating client-specific concerns.
• Gateway Routing/Gateway Aggregation: use a gateway to route requests to multiple services, or aggregate multiple individual requests into a single request, using a single endpoint. In our case, the gateways implement both these and Backends for Frontends patterns.
• Queue-Based Load Leveling: using a queue that acts as a buffer between a task and a service that it invokes to smooth intermittent heavy loads. We used message queues to balance the load on all of the microservices, including performance-critical AI services.
• Valet Key: using a token or key that provides clients with restricted direct access to a specific resource or service. In our case, we used temporary tokens to provide the customers’ access to the chatbot and forms UI, via a link in an email.

Step 3. Technology Selection and Deployment

Tools & Technologies

The microservice approach has provided us with flexibility when choosing programming languages and platforms. Due to our specific needs, we chose the following technologies:

• Python – AI microservices. Python is a de-facto standard language for Artificial Intelligence and data science, plus it has a large set of general-purpose libraries available that hallowed a smooth integration with other microservices
• C#/.NET Core – infrastructure and business-logic microservices. C# and .NET are ideal for enterprise, providing a vast set of tools for integration with enterprise software.

Other technologies we used include:

RabbitMQ – message queue and microservices integration. As we chose for our microservices to communicate via message bus, instead of direct communication via RPC (REST, SOAP, gRPC, or any other kind), RabbitMQ is ideal for that purpose. It provides great performance and resiliency, and a good way of implementing services load balancing (via competing consumers) and two-way communication (via asynchronous request-reply).

Docker/Kubernetes – microservices containerization and orchestration. Containerization is an ideal approach for microservices, as it provides a lightweight and isolated environment for them to run in, thus allowing to launch a substantial amount of services written in different languages and using different technologies, using quite modest computational resources. Kubernetes is a great way of running dockerized microservices in production, providing scale and reliability.

Redis – caching and session storage. Even though our system doesn’t store any data on itself, it still needs to maintain a temporary state of customer’s sessions. Redis serves that purpose well with its performance and robustness.

ELK (Elasticsearch, Logstash, Kibana) – log collection, monitoring, and analytics. A crucial thing when working with complex infrastructure, which is inevitable with the microservices approach, and ELK stack is offering the most complete set of tools for that purpose.

Deployment

The solution is deployed on the AWS cloud. While we have built it using only open source technologies, we chose to use several AWS-managed services on top of those technologies such as Amazon Elastic Kubernetes Service (EKS), Amazon Elastic Container Registry (ECR), and Amazon Elasticsearch Service, instead of a fully self-managed solution. This approach allowed us to:

• reduce maintenance cost;
• remain cloud-agnostic and maintain the possibility of migration to different premises.

Business Value Delivered

Abto Software has delivered a comprehensive AI-powered customer support automation software system for a leading European FinTech corporation. Two key features of the delivered solution include:

1. Automatic intent recognition of the incoming customer emails and the messages received through the company’s support portal;
2. Automatic fulfillment of the selected subset of recognized customer requests and logging of all automated decisions into Salesforce CRM.

The developed AI-based CSA system also includes a customer service chatbot integrated into the company’s support portal.

The selected microservice approach and the technologies used for deployment of the customer support automation system allowed us to build a reliable, secure, and scalable cloud-based solution that helped our client reduce customer support costs while simultaneously increasing the overall customer satisfaction levels due to ensuring timely customer service.