Business Service Assurance: It’s Time for a Fresh Approach

It is evident that the traditional approach to transport service assurance now falls short as networks have changed considerably, becoming more complex because of the recent, “rapid” cloudification of services. Running services on servers instead of on physical boxes adds other layers of complexity, which are hard to manage and which require new skill sets. Most importantly, some of the services have moved beyond the enterprises’ data centers to clouds, posing an additional challenge to CSPs: providing proof of end-to-end service quality.

In a recent discussion with a CSP executive, he described his team's challenges to prove to their customers the required service level agreements of a business service. When we talked about the details, it was apparent the team has many tools to monitor the service, yet each tool gives a narrow view of the end-to-end experience and service. Additionally, the CSP neither owns nor controls the cloud-hosted services nor has visibility into the end customer’s LAN; this added another layer of complexity. The CSP has to troubleshoot and isolate any issues that happen within its domain (the WAN) from what happens in the LAN, internet, and cloud. Such fault isolation is quite complex; the CSP has to co-relate statistics from different point solutions deployed for service assurance. The irony is that most support tickets, after troubleshooting, end up being in the nonservice provider domains such as cloud and internet.

This situation is not an isolated one. It reflects CSPs' pain point today. An industry-wide survey by RAD Data Communications confirms this: Only 24% of service calls received at a customer care center are related to the service providers’ WAN. This means that CSPs spend 76% of their efforts on issues that do not belong to their organizations.

This service call situation can be quite operation expense intensive. Consider the network illustrated in the figure. A CSP provides business access service to a customer that wants to access services hosted in a cloud. The only part that belongs to the CSP is the WAN domain. The CSP can take any proactive and corrective action in its own domain but not beyond it. Yet, the customer calls the CSP  for every issue, whether it is LAN, WAN or internet-/cloud-related, as the CSP is easily accessible. Once the call center employee receives the customer’s complaint, the issue is escalated to the transport operation team, thus keeping the operation team perpetually busy.

Isolation of issues in a multidomain service is one concern for CSPs; another issue is to ensure and prove consistent end-to-end quality of experience to the customer. These quality of experience KPIs should be rich; they must drill down to the applications and sessions the customer is using. Sessions can truly translate to the user’s experience, but this requires smarter assurance tools that are end to end experience-centric rather than the traditional network-domain-centric tools.

Although CSPs have lean service teams to support their customers and want to maintain low operation expenses, the traditional way to deal with business assurance is neither focused on scalable nor on end-to-end user experience.

The need to offload operation teams with smarter tools

Resolving issues at the edge and at the first support line is ideally the most effective and efficient approach; however, that is not always the case. Nor should you assume that call center employees’ skills need to be upgraded. What is required are new tools that help the call center employees see the big picture end to end in an easy-to-use tool to isolate and show the problem identification area to the customer and satisfy the customer without having to escalate the ticket.

A one-for-all tool must have 360° visibility into the LAN , WAN, cloud, and internet domains. It must be simple to use so that the any call center employees can utilize it. This approach will offload the second-level tech support so that it can focus on issues that relate to the CSP’s WAN network. It will also help resolve and isolate the issues faster. Consequently,  the CSP can then focus on creating new services and business expansion, while helping end customers by directing them to the network segment that causes the issue they are experiencing. Above all, the tools must focus on the KPIs related to actual users’ experiences as more customers are focusing on buying the experience rather than just the connectivity.

What needs to be changed in terms of service assurance to make this visibility happen? How can a  CSP solve these opex issues and run the network in a streamlined manner?  Can the CSP re-use the tools and systems deployed already in the network?

The answers are yes, and are the subject of the second blog in this series, coming soon.