The clock for both should start when IT learns about the incident, either due to a user call or because IT detected it. Look at it from the user perspective. Say you call the helpdesk, the incident then sits idle for a day waiting for the appropriate support group to accept the ticket and start working on the incident, which takes another day. What was the resolution time? 1 day or 2 days? I bet the user will say it took 2 days. He won't be interested in the fact that the actual work only took 1 day.
The answer to your question actually sits in Availability Management, in the red book, point 8.9.9 The Expanded Incident Lifecycle.
The response time is the time between the detection and the diagnosis. ITIL defines "detection" as the point when the IT organization is made aware of the incident.
The Repair Time is the time between diagnosis and recovery. It represents the work that is done.
It is followed by the Recovery Time, which is the time lapse between recovery and restoration of the service.
The sum of all 3 gives you your Resolution Time from a user perspective.
But if you want to be realistic, you need to add the Detection time to the equation. Your true downtime is from Incident to Restoration, not from detection to restoration. You could validly argue that it is IT's responsibility to detect incidents the quickest way possible, and that ideally, tools should report incidents automatically. IT should not wait on a user to be affected before taking action.
my 3 cents (due to inflation) _________________ BR,
Technology Consulting | Service Excellence
Red Badge Certified
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum