A report that measures case outcomes against today's SLA configuration is answering the wrong question. The question is not what the policy says now. It is what the policy required when the case was open and the clock was running. A team that tightened its resolution targets last month cannot fairly judge December cases against the new numbers, but that is exactly what happens when reporting reads only the current policy. The output looks precise. It is not.
The fix is a snapshot: an immutable copy of the SLA policy written onto the case at the moment the case is created or the policy is selected. The snapshot lives with the case record and outlasts any later edit to the policy definition. This article describes what the snapshot captures, what the reports show, and why that matters for anyone who has to explain a quarterly SLA figure to a customer or an auditor.
What the snapshot holds
When a policy is selected for a case - whether the default, a tag-specific policy triggered by a matching tag, or a policy set manually - the system records a set of fields that together describe the commitment that governed that case:
- Policy source - whether the policy came from the default configuration, a tag match, or a manual override.
- Policy tag or name - the tag that triggered the selection (for tag-specific policies) or a label identifying the general default.
- First-response objective and minute threshold - the target that was in effect when the case arrived.
- Resolution objectives and minute thresholds per priority - the target for Critical, High, Medium, and Low priorities as they stood on the case's opening date.
- Overall and priority target percentages - the attainment thresholds used to assess the selected policy.
- Working-hours basis - the clock window (for example, 9-to-5 local or 24/7) that determined when the countdown ran.
These fields are stored alongside the case, not derived from live configuration, so a later change to targets or working hours leaves the historical record untouched. The report asks the case what it was measured against, not what the current settings would guess.
Why policy drift breaks untrustworthy reports
Without a snapshot, SLA reporting relies on the assumption that today's policy describes yesterday's commitments. That assumption fails under routine operations. A team changes a resolution target from 480 minutes to 240. A quarter-end report pulls the current 240-minute value and applies it to all open and closed cases in the period, including those that were governed by the 480-minute target. The report says 30% of cases breached the 240-minute window. The actual breach rate under the policy that was in force at the time might have been 8%. The difference is not a measurement error. It is a reporting design error.
Policy drift also hides over-performance. When the old target was tighter than the new one, cases that met the old standard might look like they failed under the new, weaker requirements. Neither direction is useful. Both undermine the team's ability to tell an honest story about what happened.
How the report separates populations
A policy-aware SLA report groups cases by the policy that actually governed them. The report distinguishes three populations:
- Default-policy cases - no matching tag, carried the general SLA policy.
- Tag-specific policy cases - matched a tag that selected a complete policy, with its own targets and working hours.
- Manually set policy cases - a policy was applied directly to the case outside the tag-selection path.
Each population shows its own set of objectives, targets, and breach counts. A single dashboard can display both the on-site policy's 2-hour first-response rate and the remote policy's 4-hour rate without blending them into a single blended percentage that misleads everyone.
This separation is not a cosmetic feature. It is the difference between a report you can act on and a report you will spend the next meeting explaining away. When a customer asks why an on-site case took three hours to acknowledge, the team can open the case, see the 2-hour target that was in force, and explain the gap. When an internal audit reviews SLA adherence, the auditor sees the commitment at the time, not a recalculated number.
Where the snapshot fits in the control story
The snapshot is a record of the commitment that applied. It complements the audit trail on the case, which records how the case changed over time. Together, the two records answer the two questions a reviewer will ask: what commitment applied, and what happened during the work?
The tag-specific SLA release overview describes how policies are selected by tag and how the deterministic rule resolves conflicts. The configuration guide walks through building and testing tag-specific policies before rollout.
A report that can only read the current configuration is not a report. It is a guess with a number attached.