Automate Order Fallout Resolution Using Self-healing Framework

Most Digital Service Providers (DSPs) face a common challenge of meeting due dates for their customer orders. The instability and delay in order fulfillment are increasing with the introduction of complex convergent services, which require bundling of different product offers. These complexities get further compounded with,

• Increasing mergers and acquisitions in the DSP industry
• More connected devices due to enhancement in IoT and 5G technologies
• Increasing demand to offer highly customized and multifaceted orders

Any delay in order handling due to fallouts can lead to significant customer churn and revenue loss. Hence, a swift resolution of fallouts is a prime necessity. This article details how DSPs can create a “self-healing framework” for faster resolution of order fallouts in their order-to-billing journey. It further deep dives into core elements of the framework, highlighting key recommendations to effectively build it.

Creating a “self-healing framework” to resolve order fallouts can help DSPs reap major business benefits

For any order fallout in the order handling journey, the user first logs the issue in the ticketing tool. These tickets get piled up in the backlog and then picked up by the operations team to find the root cause and provide a relevant fix. Such traditional approach to ticket resolution involves a series of complex manual processes, which requires significant time and resources to fix it. These fallouts, if not resolved quickly, has cascading business such as:

• Constant high backlogs leading to delayed ticket resolution and lengthier cycle time per ticket
• Delay in customer provisioning because of data integrity or process issues
• Overhead during the month-end billing cycle and increased escalations

This mandates DSPs to look for smarter ways to quickly resolve such fallout issues. Building an automated approach to resolve fallouts can help DSPs to improve order-to-activate timelines and reap major business benefits.

Fig: Migrating from traditional approach to automated approach for ticket resolution leveraging self-healing framework.

The proposed architecture of “self-healing framework”- Achieve automated resolution of order fallout issues & recurring requests

Fig: Proposed architecture diagram of “self-healing framework”

Orders usually don’t meet the target due dates because of various reasons. This can happen because of fallouts due to data integrity issues, incorrect/missed processes, or even migration issues. Also, several recurring requests such as frequent user access requests, groom order updates etc. add further delay in processing the orders. All such order fallouts and recurring requests can be processed using the self-healing framework.

The order ID for any fallouts can be automatically captured from the system log files using the fallout capture module. This can also be logged in by the user in a unified portal. Having LDAP authentication to login is essential, as it allows securely authenticating multiple applications with just one credential. This offloads user validation workloads, resulting in significant performance improvement. The order ID and request ID captured in the portal can be processed using the issue processor and service request processor respectively.

Issue processor is the core element of the framework as it provides an automated resolution of order fallout issues. The key elements of issue processor and its functioning is covered below in detail.

Issue Identifier

Order can fallout while processing through different modules such as order validation, logical provisioning & design, customer integration, order billing, and order due date. The issue identifier should be built with a set of validation rules to scan different modules in order processing and identify where the order is failing. It should be able to capture the following key information:

• Module in which the order fails
• Specific query leading to the fallout
• Error number
• Error message

Root Cause Analyzer (RCA)

The next step is to run validation logic across several defined cases to identify why the order is failing. This can be done by creating RCA module, which holds an inventory of logic to identify the issue type.

Below are some key recommendations for building this module:

• Categorize & embed scenarios into the RCA config table for easy classification and solution
• Develop logic based on the database used – (Oracle, MySQL, Mongo or Hive)
• Define case type & description in the config table to pass this info to the Solutionizer for providing logical solutions
• Run multiple validation checks based on the RCA config table

Solutionizer

This should be built with functionality to provide an automated fix to the issue leveraging pre-defined customized scripts embedded in the framework. Whether it is a data integrity issue or a process-related issue, the Solutionizer module should execute the corresponding fix. Logical steps provided by Solutionizer can be executed by the user to resolve any process issue. It is equally important to have a feedback mechanism, which provides insights into the additional missing scenarios. This brings continuous improvement by adding the missing scenarios into the RCA config table.

Business & operational benefits for a leading Digital Service Provider (DSP) in North America

For one of the major product lines, 75% of customers’ fulfillment orders were not meeting the due dates because of order fallouts. This significantly impacted the order-to-activate timelines. The majority of fallouts were because of process issues, data integrity issues, and migration issues. Leveraging the self-healing framework helped the DSP to provide automated resolution to these order fallout issues and achieve major expected business benefits.

• Reduction in operational cost for ticket resolution by 48%
• Improvement in incident resolution time by up to 98%
• Improvement in customer satisfaction by timely meeting the due dates

By Muthukumaravel S