Nov 102011
Customers will expect you to deliver the quality of service you have committed in the presales phase. Most of the operators, however, fell short on delivering this expectation and service outages occur every time.Most operators who does not trust their current network, do not implement any customer SLA management process. Lacking of an end to end view, these operators just accept trouble tickets coming from the customer side. Also since, most telecommunications regulatory bodies enforce customer SLA management processes, CSP calculates the SLAs based on customer facing trouble ticket information.

This reactive, primitive approach is no longer welcomed by today’s corporate customers. These customers expect more reporting capabilities that will also include outages that they are not aware of.

If the customer has a current SQM process, this could be an enabler for an effective customer SLA  management system. When a process name includes  “Customer” in it, you should be careful. If you show an outage to the customer in a report, you give them the option to claim a rebate. Therefore, we, as CSPs, need to adjust the outages after the outage has already occurred.

Most SQM systems will not allow you to edit already occurred outage events.  Therefore, these events should be exported to another system(NW DWH, EDWH ) for further correlation with force-major outage information.

If the CSP has not invested in an SQM solution before, they could utilize a Network Analytics (NW DWH) solution but this will not provide all the benefits that an SQM system brings. The best combination would always be SQM and Customer SLA Management solutions working together in a fully managed reporting environment.

OK, but how can we correlate force-major outage with a service outage information coming from a network probe for example? Or the question should be, how  can we identify the force-major? The key component in here could be the service management platform where the problem management processes have been implemented. SQM systems will auto populate resource facing incidents for proactive recoveries. These incidents can after be inspected for a common root cause and if the root cause of the outage is not because an operator fault, it can be excluded in the force-major list.