trouble is resolved and the ticket closed, the trouble system should be able to send commands to the network manager to clear faults. Conversely, when the network manager detects that the fault is clear, it should be able to send commands to close trouble tickets. In an advanced integrated environment, the trouble management system could provide mean time to repair estimates based on the specific problem. This information could then be used for pro- active customer care. Dispatch. Once the trouble is identified and a ticket is issued, dispatch systems must be notified in order to send the right technician to the right place at the right time. This means passing detailed trouble ticket and alarm information to present the exact nature of the problem to the dispatch system. WEB-BASED CARE TRANSACTIONS Trouble Entry/Trouble Status. As mentioned, trouble tickets can come from within the IIC, but more and more, customers are entering trouble tickets themselves, generally through a Web portal or some extension of the trouble management system. If entered through the Web portal, the portal must be linked closely with the trouble ticketing process. In some cases, this can involve integration with more than one trouble ticketing system - one that is network-focused, and the other, customer-focused. Chapter 6 - Integrating the OSS Platform There can also be third-party trouble interfaces, especially in multi-IIC scenarios. For example, an IIC might experience a fault and correlate it to a supplier's network, such as an ILEC loop. In this case, trouble tickets would flow from the IIC, over an interconnection gateway, and into the supplier's trouble interface. Beyond entry, trouble status is the key component to service assurance. The customer must know the nature of the problem and how long it might take to fix. The level of detail available depends on an IIC's processes, i.e. how well its people update trouble handling logs or what information the trouble manager can send to a Web portal or CRM system. Most important is th