Each clock needs a defined start and stop
Response can mean an automated acknowledgement, human engagement or the start of diagnosis. Arrival can mean reaching the address or gaining access to the affected equipment. Those definitions can produce very different results from the same incident timeline.
The report should identify the event that starts each clock and the evidence that stops it. The relevant coverage calendar matters as well: elapsed time and time measured only within agreed service hours answer different questions. A target is difficult to interpret without those definitions.
Google's service-level guidance distinguishes a measured indicator from its target and emphasizes measures relevant to the user experience. Applied to onsite support, that principle means a response target should remain visible alongside a measure of the business service's condition. Neither measure should silently stand in for the other.
Arrival is useful only when intervention becomes possible
A technician can arrive on time and then wait for an escort, replacement equipment or a remote administrator. Those delays may have different owners, but they still extend the period before useful work begins. Recording arrival alone loses the explanation.
A more informative timeline records when the technician could access the work area and when the required dependencies became available. This distinguishes travel performance from site readiness and technical execution. It also helps identify where a recurring delay can actually be reduced.
That distinction should improve coordination rather than become an argument about who gets the minutes. The business needs the whole timeline even when commercial reporting excludes a particular interval. Otherwise, a service can appear to meet every individual commitment while the end-to-end experience remains poor.
Mitigation and permanent repair can occur at different times
Moving work to an alternate device or connection can restore a useful level of service before the failed component is repaired. That is a meaningful operational result. It should be described precisely enough that the business understands any remaining limits.
A site operating on a reduced-capacity backup path may be able to transact while large transfers remain impaired. Calling the site simply restored hides the difference between normal operation and an accepted degraded state. Calling it wholly down ignores the value of the mitigation.
The report can preserve both events: when the required business function resumed and when the permanent correction was completed. This supports better decisions about spares, fallback capacity and repair priority without forcing every incident into one ambiguous restoration label.
Averages can conceal the incidents that dominate disruption
An average repair time combines incidents with different causes and dependency chains. It can improve while a small group of sites continues to experience very long outages. Separating incidents by service, failure class or dependency can make the underlying pattern visible.
The useful question is what accounts for the long tail. It may be part availability, restricted access, repeated diagnosis or a specialist who is unavailable during the service window. Each calls for a different improvement. Buying a faster acknowledgement target will not necessarily change any of them.
The business should also retain the number and duration of interruptions behind a summary measure. One extended outage and many short disruptions can impose different operational costs even when their accumulated downtime is similar.
Service commitments should target the controllable delay
The best measurement model connects the customer-visible interruption with the provider's actions and the dependencies between them. It shows whether faster dispatch, better preparation, local spares or a usable fallback would change the outcome. Response time remains worth measuring, but it earns its meaning from its place in that larger recovery timeline.