Sign in

Blog · Board and management reporting · Customer service

Report SLA results across contract-version changes

Assign versioned SLA targets to service obligations and distinguish original contractual reports from restated or like-for-like comparisons.

The short answerStore dated target versions and define which event selects them. Freeze issued results, then label corrected or comparable restatements separately so changed targets do not masquerade as changed service performance.

An account changes its response target from eight hours to four hours halfway through the quarter. The next report shows a lower attainment percentage. That may reflect tighter terms, slower service, a mapping error or all three. A target version on each obligation separates those explanations.

The per-account SLA guide owns the principle of measuring against the account's own agreement. This method handles the timing of changed agreements and report versions. It does not determine which legal interpretation of an amendment should prevail; the authorized contract owner supplies that policy.

Keep targets as dated records

Store account, obligation type, priority band, target duration, calendar version, effective_from, effective_to, source reference and approved version identifier. Keep previous rows. A new target should not overwrite the value used to produce last month's issued result.

Use nonoverlapping effective intervals unless the agreement genuinely needs another selection rule. For technical matching, a half-open interval includes effective_from and excludes effective_to. Make the policy's time zone explicit. A change effective at local midnight is not necessarily effective at midnight UTC.

Record separately the date the amendment was entered into the reporting system. An agreement effective September 15 but loaded October 2 can affect a prior-period restatement. Effective date, system-entry date and report-issue date answer different questions.

Agree which event chooses the version

Possible policies select terms at ticket opening, obligation-cycle start, a specified contractual event or another documented basis. Do not assume the latest version applies to every old ticket. Some amendments govern newly opened work; others govern ongoing obligations. Ask the contract owner and preserve the instruction in the reporting policy.

Atlassian documents configurable SLA start, pause and stop conditions. Those conditions demonstrate why an obligation's start event and cycle history matter, but the product documentation does not decide the effect of a customer's contract amendment. SLA conditions.

A synthetic change-over example

Account A has an eight-business-hour response target before September 15 and a four-business-hour target from that date. For this example only, the signed reporting policy selects terms at obligation opening and leaves existing obligations on their original version. The business calendar is unchanged.

Obligation Opened Counted response time Applied target Result
C-01 September 14 6 hours 8 hours, V1 Pass
C-02 September 16 6 hours 4 hours, V2 Breach
C-03 September 17 3 hours 4 hours, V2 Pass

The contractual opening-cohort result is two passes from three completed obligations, or 66.7%. Applying the latest four-hour target to every historical row produces one pass from three, or 33.3%. That second calculation is a uniform-target comparison, not the original contractual result under this example's policy.

Conversely, applying the old eight-hour target to all three gives 100%. Neither restated comparison should silently replace the issued contractual report. The counts are tiny and synthetic; they illustrate selection logic, not an expected service performance level.

Distinguish three report products

An original report preserves the inputs and rules used when it was issued. A corrected contractual report fixes an error, missing amendment or bad event using the terms that should have applied. A like-for-like analytical comparison applies a common stated rule to study changes independent of target changes.

Label report type, target-selection policy, calculation version, source-extract timestamp and predecessor report. A restatement log should identify affected obligations, the reason, previous result and revised result. Correcting a duplicate event is different from choosing a tighter comparison target.

For the example, a comparison pack can show 66.7% contractual, 33.3% on uniform four-hour terms and 100% on uniform eight-hour terms. The differences expose the rule effect; they are not three competing truths about the same contractual question.

Check joins at change boundaries

Test obligations immediately before and exactly at the effective instant, tickets spanning the boundary, reopened cycles, changed calendars and overlapping target rows. Count zero-match and multi-match cases before calculating attainment.

A ticket with two applicable versions is an exception, not two tickets. A missing effective_to can make an old row overlap every later version. The ticket-history workflow explains file reconstruction, and the clock guide handles calendar arithmetic after the correct version is selected.

Explain the movement to the service owner

Show volume and outcomes by applied version, alongside comparable within-version results where data permits. Use the case-mix comparison when priority distributions also change. Avoid attributing every percentage-point movement to staff performance.

Bring the amendment history, source target rows and a small authorized event sample to agree a reporting scope. A useful scoped analysis preserves evidence and makes restatements reviewable; it does not automatically interpret legal amendments or promise a live contract-system integration.

Questions people ask

Should the latest target apply to every historical ticket?

Not automatically. The authorized contract owner must specify which event selects the applicable version and how ongoing obligations are treated.

What makes a restatement reviewable?

Keep the original result, revised result, affected obligations, source and target versions, reason, reviewer and issue date.