Even in a scenario where service restoration can't be achieved, we procedurally follow a series of management escalation to agree how to proceed with the handling of the incident to come to a mutually agreed conclusion (between ourselves and our clients) over how the incident ticket can be closed and overall solution development pursued and completed. If this requires a problem management engagement, the management escalations and their decision would be recorded in the incident work log, the problem ticket opened and cross-referenced to the incidents unique identifier and then the incident itself closed.

I've been challenged on this approach by a client, who, in the scenario described above, thinks the incident ticket should remain open whilst the problem management activity is carried out (root cause analysis, fault isolation and error removal, presumably with all the associated CM activities that would need to complete before the problem ticket can close) and that the incident ticket doesn't close until the final solution is in place and hence service restored.

I'm certain our standard approach is the most effective, efficient and correct one; however, I can't find any definitive guidance on this in any of my ITILv3 documentation.

Can anyone point me to ITILv3 best practice direction on guidance on when incident tickets should be closed with regard to the instigation of problem management specifically in the scenario where normal response to incident handling can't actually restore the service. Doesn't matter which way the direction and guidance goes, just as long as it provides me with some independent collateral which resolves this discussion.

Many thanks

Guy Davies