y the service support desk, the resource that is causing the issue is isolated and the trouble ticket is assigned to the resource support desk sitting at the network operations center (NOC) owning the resource that has been identified as the cause of the problem. The identification of the resource that caused problems in a service is done by analyzing event records generated by the resources. It is expected that the devel- oper creates enough logs to troubleshoot and fix an issue. The resource team will then analyze the issue and isolate the cause of the problem. If the problem is caused by a module developed by the service provider, then the ticket is assigned to the team that developed the module to fix the issue. On the other hand (as in our example) if the problem is caused by a module developed by an external vendor, then the trouble ticket is assigned to the vendor trouble submission queue. When the vendor is notified about trouble in their product, based on the sup- port level offered, the vendor will work with the service provider to resolve the issue. Once the issue is fixed, the information is communicated to the service pro- vider. The service provider will update the status of the trouble ticket as closed in the ticket database. This activity will generate an event to the customer support desk, SO that they call up and inform the customer that the issue has been resolved. The customer can call the customer support desk not just to enquire the status of the trouble ticket but also to close the ticket if the issue was temporary or was caused due to some issue that the customer was able to fix as part of self-service. It is therefore important that all the processes that update the ticket status with the database, first queries the database and checks the status before making any updates. In addition to ticket status and problem description, the trouble ticket will also contain a history of activities performed to resolve the trouble ticket, dependencies on other trouble tickets that need to be resolved 