Solution Architecture
The following sections briefly explain each of the core components depicted in the diagram above.
Channel Connectors
A Channel Connector is a wrapper implementation between a Customer Channel (such as WhatsApp, Faceb/ook, Webchat) and Expertflow CX to exchange customer communication on the channel. Therefore, it is not considered to be a part of the core architecture of the solution.
When an inbound request is received from a customer channel (WhatsApp, Facebook), it is received on the respective channel connector. From the channel connector, it is then transformed into a format readable by Expertflow CX core components to be navigated across the application.
For more details, see Channel related terms -> Channel Connector.
Expertflow provides out-of-the-box channel connectors for all supported channels and provides interfaces to develop channel connectors on your own to customize the channel flow, with a Channel Provider of your choice.
The following channel connectors are available:
WhatsApp via Dialogue 360
WhatsApp via Twilio (for text messages only)
Web connector for web chat
Facebook connector for Facebook
For more details, see Channel Connector Developer Guide to learn how to develop your own channel connector.
Customer Channel Manager (CCM)
Customer Channel Manager is responsible for creating and managing channel sessions on customer channels. When a new request is initiated by a customer (a call or a message), it is first received by the Channel Manager component from the respective channel connector.
If it is the first message from the customer on this channel, CCM tries to identify the customer with Customer Interaction Profile component. If a customer from this channel identity already exists, CCM creates a channel session for the identified customer.
Next, CCM communicates with the Conversation Manager to confirm if a conversation for this customer already exists. Conversation Manager returns a conversation ID to CCM, for CCM, to add this channel session to the returned conversation.
CCM adds this channel session to the returned conversation for the customer and agents to communicate over the channel session.
Conversation Manager
This component is responsible for managing conversations, i.e. creating, closing, updating, adding/removing participants to/from conversations, and managing states of a conversation.
Conversation Controller
This is said to be the brain of Expertflow CX which is responsible for taking dynamic decisions on a conversation to ensure the smooth flow of the conversation. These decisions may include:
Making a request for a human agent if no agent is in the chat
Closing a conversation
The Conversation Controller calls REST APIs of Conversation Manager to suggest actions on a conversation such as closing a conversation. The Conversation Manager then executes actions as suggested by the Conversation Controller.
Bot Framework
Bot framework acts as a translator between the conversation bots (Rasa, AmazonLex, Dialogflow,...) and the rest of the Expertflow CX components. This translation layer receives all type of conversation events sent to/from the bots and converts them into a language that is understandable by the receiving party.
In addition, it is also responsible for configuring, adding, removing a bot in the system.
This layer encapsulates the following components:
Conversation Bots (Rasa, Amazon Lex, Dialogflow, Custom...)
It's an interface to 3rd party bots such as Rasa, Amazon Lex. via Custom Bot Connector.
A 3rd-party, Conversation Bot may respond either directly to the customer, or whisper/suggest answers to the agent who's handling the customer based on the bot training.
Expertflow supports Rasa, and Amazon Lex, as out-of-the-box bot connectors.
Customer Interaction Profiles
This component is responsible for the generation and management of the customer profiles. When a new conversation is initiated by the customer, CCM asks CIM Customer to check and confirm if the customer with this channel identity exists. So if it exists, it by default, gets linked to the identified customer profile. However, if no customer profile exists, an anonymous customer profile is created and linked to the conversation.
See Agent Capabilities to learn more about how to create customer profiles and link/relink conversations with customer profiles.
Routing Engine
Routing Engine is responsible for the actual routing of conversations to humans if the involvement of a human agent is required.
When there is a request to involve a human agent (either generated by the bot or by the customer) in a conversation, it is first supposed to be enqueued in a precision queue by the Routing Engine. This is the queue which is mapped to the customer channel from where the customer initiated the request. See Administrator Guide to see the linking of queues and channels.
Based on the routing logic of the queue, Routing Engine creates an agent task and looks for the most appropriate agent to answer the customer request.
Once an agent is found, the Routing Engine reserves the agent to answer the request and assign the agent task to this agent.
See Precision Routing to see details on how queues and routing logic inside queues can be defined, and how tasks are routed/assigned to agents based on the queue logic.
Agent State Manager
Routing Engine has another sub-component, called Agent State Manager which is responsible for managing:
Agent’s global state - Ready, Not Ready
Agent’s MRD state - Ready, Not Ready, Active, Busy, Pending-not-ready
Agent's task state - Created, Queued, Reserved, Active, Closed
Agent Manager
Agent Manager serves as a communication layer between Agent Desk and the rest of the core solution components (Routing Engine, Conversation Manager, IAM).
All the real-time events are exchanged from Agent Desk through the Agent Manager. These events include:
Agent State Changes
Conversation State Changes
Messages Exchange
Agent state changes include changing and syncing of agent states (Ready, Not Ready) and MRD states (Ready, Active, Busy, Pending-not-ready, Not Ready) to/from Agent Desk (or any custom Agent App) with the Routing Engine's Agent State Manager component.
Conversation events include alerting a new conversation, accepting and leaving a conversation. Agent Manager communicates with the Routing Engine for reserving an agent and routing and showing the conversation to the agent frontend (Agent Desk or, any custom Agent App).
It then also communicates with the Conversation Manager to return the conversation and all the data about the conversation (messages, history, customer identified, channel session data, conversation data) to be displayed to the agent.
Also, for the real-time messages exchange from the agent to customer or from customer to agent over a conversation, these messages are propagated through the Agent Manager.
Last but not the least, Agent Manager also communicates with the IAM solution, called Keycloak, to get the agent logged into the system and return the roles, permissions for access management. After the agent gets logged in, it communicates with the Conversation Manager to check and return if there were any active conversations opened with this agent (e.g. in case of agent's browser failover scenarios).
Agent Desk
Agent Desk is the agent desktop that serves as a frontend interface for handling of agent states and conversations. It is a browser-based application that can be opened as a standalone interface or can be embedded inside a third-party system such as CRM, or Cisco Finesse.
The Agent Desk is the default agent application provided by Expertflow. However, it can be replaced with any custom agent interface built by the customer, partner, or EF on demand, using Agent Desk Developer Guide.
IAM
IAM (Identity and Access Management) solution allows businesses to manage users and their access rights to the system.
For IAM, we use Keycloak which is a third-party, open-source application for the creation of users, user roles, and their permissions.
For more details about user roles and permissions for Agent Desk, see Security and User Permissions
Reporting
The reporting component comprises of two sub-syste
ETL for historical reporting
REST APIs for real-time reporting
Realtime dashboards
For real-time reports, the reporting component exposes REST APIs to provide real-time stats on a dashboard. The solution comes with some default, supervisor dashboards which provide summary and detailed statistics about queues, MRDs, agent states and details about the active/queued conversations.
See more details on dashboards
Historical reports
Expertflow CX comes with a separate, SQL-based reporting DB which currently supports the following SQL databases:
MySQL
MSSQL
All the transactional data of customer conversations is replicated into the reporting database from the source database (i.e. MongoDB) by scheduled ETL jobs. The jobs run in periodic intervals as specified during the deployment of the solution.
Note that the reporting database is used for historical reporting only. Therefore, a conversation is available in the reporting database only once it is closed and becomes a part of the history.
Communication Workflow
The following section describes the flow of communication and the path that each new inbound requests consumes when it reaches Expertflow CX.
For this example, a customer, John, approaches the contact center through web chat to ask a question.
John starts a chat from web channel.
CCM receives John's request and tries to identify the customer by consulting with the Customer Interaction Profiles module.
Since John's channel identity for the web channel exists in John's profile, the Customer Interaction Profiles module returns John's profile to CCM.
CCM checks if this is the first message of this customer on this channel. Since John has just started the chat, CCM creates a new channel session of John for web channel.
CCM then checks with the Conversation Manager to see if there already exists a Conversation for the customer, John. Since this is the first time that John has started the conversation, Conversation Manager creates a new conversation and adds this channel session to the new conversation.
A Conversation Bot greets John. John starts chatting with the bot.
John requests to talk to a human agent, or sends a message that was not understandable by the Conversation Bot.
The Conversation Controller asks Routing Engine to assign an agent to this conversation.
The Routing Engine enqueues this conversation to the queue which was mapped to the channel which the customer used to initiate the conversation.
The Routing Engine creates an Agent Task and looks for an available (those are in Ready or Active state) and the most appropriate (based on the queue logic) agent to talk to the customer on this conversation.
Once found, it reserves the agent and the Agent Task is assigned to the reserved agent.
The agent starts seeing incoming alert with an "Accept" button to answer this conversation. The agent accepts.
The Conversation Manager returns the customer conversation to the Agent Manager which then communicates with the frontend component, i.e. Agent Desk to show it to the agent.
The communication between the agent and the customer goes on.
If the agent drops or leaves the conversation, the conversation still remains active on the system unless the customer closes it. However, the customer would see real-time notifications of agent joining, leaving the conversation.
When the customer leaves, the channel session would be closed but the conversation still remains active on the agent unless the agent closes it manually (this is in case if the agent wants to give some after-call comments, or wrap-ups to the conversation)
Also, in case the agent sends any message and the customer does not respond within the
Customer Inactivitythreshold, the channel session is closed by the Conversation Controller.