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.