In this article, we discuss how firms are evolving their application stacks to better integrate enterprise communication flows into their core systems and processes — seeking to unlock new efficiencies and business capabilities by exploiting major advances in Natural Language Processing (NLP).
What is Enterprise Communication?
In a business context, communication is defined as:
“the timely flow of accurate information between the different parties needed to complete a task.”
Efficient communication forms the basis of smooth business operations — sales, customer services, business process management, and many other important business functions.
Enterprise communication flows may be structured, or unstructured.
- A structured communication uses a machine-readable data format and typically follows a formally defined business process. A good example is placing an electronic order on a stock exchange and receiving execution reports as the order is filled.
- Unstructured communication is much more fluid and variable as they deal primarily with human language — written or spoken. A good example is taking a customer order over a telephone, or handling a customer complaint via email.
Historically, businesses have designed their application stacks almost exclusively around processing structured communication flows — most applications generally perform analytical processing (OLAP) or transactional processing (OLTP) on these flows.
While it is true that some applications do process unstructured communication data (for example, a compliance application that monitors email and chat data) their functional scope is severely limited as they do not have a good understanding of the semantic meaning or intents embedded in the language.
Over time, the difficulty in processing natural language has led to unstructured communication flows being largely handled manually, and, as a consequence, firms adopt high levels of organizational debt.
In many firms, employees spend ~40% of their time in email and chat channels, and it is not uncommon to find large teams of people aligned to shared mailboxes handling email traffic:
- Customer-facing teams have to read all inbound emails, manually categorize and prioritize them, and then route them to the correct team to action (“triage”).
- Internal teams aligned to specific processes/tasks have to read each request, manually extract data attributes, re-key data into internal systems, and then manually respond to the requesting team (“humans as APIs”).
- More broadly, email and chat channels are used to work around system limitations, supporting a diverse range of ad-hoc queries, process exceptions/edge cases, and, in many cases, entire business processes.
Due to the nature of the data and diversity of the processes/tasks involved, firms often have very poor visibility of these communication flows, and as a consequence tend to underestimate the scale of effort required to support them.
Organizationally, it can be challenging to design an efficient operating model around the processes/tasks, and so teams tend to be highly “sticky”. As change and continuous improvement is difficult to achieve, the teams often get outsourced — further reducing transparency.
Similar to technical debt, firms suffer from high levels of organizational debt stemming from their communication processes.
Furthermore, these communication flows are often highly inefficient due to inherent limitations:
Accuracy — Frequent manual intervention creates data inconsistencies, meaning communication is inaccurate, leading to further intervention to manually correct and enrich with reference data (“swivel chair” jobs).
Timeliness — Communication can be delayed due to incorrect routing of requests, prioritization, high volume, or lack of resources. This results in high process latency — often measured in hours or days.
Natural Language as an API
A typical enterprise architecture consists of two separate infrastructures — a core application stack supporting structured communication, and, in parallel, a largely manual capability supporting unstructured communication.
The latter is performed in parallel to, and largely outside of, the core application stack. Where communication flows do touch systemic flows, integration is typically crude.
This separation limits the business at a fundamental level. For example, it is virtually impossible to create a holistic picture of the customer journey, to understand the true cost to serve, to identify capacity constraints, or to map every step of a business process.
What would be ideal is to find a way to bridge these two worlds and a way to bring together structured/unstructured data consistently.
For example, if we could capture a customer inquiry over email and automatically convert it to a structured request that is then used to call a business service and automatically provide a response to the customer, we could significantly reduce manual effort and — perhaps more importantly — improve communication efficiency.
This is the fundamental concept behind “Commsware” — to use NLP as a bridge between unstructured communication channels and the core application stack.
From a design and implementation perspective, this involves deploying middleware that sits between communication channels (email, chat, telephony) and core business applications.
An example of “Commsware” is the Re:infer platform.
Re:infer is an enterprise-scale NLP engine that connects to real-time communication sources and automatically converts unstructured communication into structured events that drive action.
The platform is usually deployed as a centralised firm-wide solution for all NLP tasks, meaning it can be leveraged by any application or business function across the enterprise.
A typical deployment would have real-time integration with email, chat, and CRM channels, and feed structured events to multiple destinations such as RPA, workflow engines, core systems, etc.
Re:infer also provides powerful communication analytics, allowing users to mine historical communication data to discover processes, inefficiencies, and risks buried in the data.
Benefits and Operating Model Considerations
The benefits of deploying Commsware are threefold.
1. Increases communication efficiency
First, it increases communication efficiency, providing better data guarantees as evidenced by:
- Increasing response times / reducing process latency
- Increasing data consistency and accuracy
- Reducing exceptions, for example misrouting/missed requests
This in turn leads to reduced manual intervention driven by:
- Automatic triage and routing
- Reducing the need for content extraction and re-keying
… and enables continuous improvement through:
- Improved visibility through real-time analytics
- Identification and removal of organisational debt
2. Enables new business capabilities
Second, it enables new business capabilities, driven by a comprehensive (rather than fragmented) view across all enterprise data.
For example, firms can build a complete view of the customer journey, identifying all touch points with the customer and capturing a complete picture of customer behaviour.
This allows firms to create personalised digital experiences, if desired.
3. Drives digital transformation
Third, it provides insights to drive digital transformation. Communication data contains a wealth of hidden information including customer feedback on product improvement, failure demand, internal process inefficiencies, manual intervention, capacity constraints, and risks.
Our clients are using these insights to build real-time performance metrics for different business areas, and prioritise transformation investments accordingly.
Some of our larger clients have created a consolidated digital transformation operating model, pooling spend and resources across RPA, workflow, and mandatory/regulatory programmes.
This has enabled them to roll out a centralised Commsware capability and prioritise all transformation spend and implementation activities across those programs.
With this approach, it is possible to accelerate RPA adoption and workflow implementation while maximising return on investment.
