ed repository of troubles that needs to be fixed. This helps to improve the service quality and the response time in fixing a trouble condition. There will be different kinds of reports that can be generated by trouble ticket manager, which will give information on network equipments that get faulty most of the time, wrong configurations that degrade performance, efficiency of bug fixing team in fixing problems, map faults to modules or release products from specific vendors, customer quality of service, and issues reported by cus- tomer including outage of service. A trouble ticket can be raised by the cus- tomer, the service provider, or some predefined fault logs will automatically register as a trouble ticket. These tickets are then assigned to the resolution team. Based on how critical the trouble condition, different levels of supports will be offered and there is usually a dedicated team to handle each level of support. Support level can map to the services offered like level zero support might involve calling up the person who raised the ticket within an hour and providing support or it could mean that the trouble needs to be closed within a day. These items are explicitly slated in the SLA. When a trouble ticket is raised and needs to be assigned to a support person, the work force management module provides necessary inputs on the best person to solve the trouble condition. The work force management module has details on the skill sets and location of the technicians. It also maps technicians to specific trouble tickets, like whether the technician is free or working on a ticket, was there a change in the ticket status, or was the ticket reallocated to some other technician, and SO on. Consider the trouble ticket deals with a faulty switch in Dallas, Texas. So the trouble ticket man- ager assigns the ticket to a technician in Dallas based on input from the work force module. After fixing the switch, the technician can change the status of a ticket, for reconfiguration of switch by an operations team in 