Blog · Board and management reporting · Customer service
Choose and reconcile SLA ticket populations without hiding unresolved, reopened or excluded work. Compare completion and opening cohorts on synthetic data.
A service report can improve when the team stops closing its most difficult tickets. If its denominator includes only completed tickets, unresolved breaches disappear from the percentage. The arithmetic may be correct while the population answers a narrower question than the reader expects.
The SLA definition and per-account guide establish the measure and target source. This page chooses which observations enter a particular report. There is no universal denominator for every service contract; the report must name its counting rule.
Decide whether a row represents a ticket, a response obligation or a resolution cycle. A reopened ticket may have one ticket identifier but two completed resolution cycles. A ticket with separate response and resolution targets also supplies two different obligations. Counting all of these as interchangeable tickets produces an unexplained denominator.
Record the ticket identifier, cycle identifier, account, obligation type, start instant, due instant or target, completion instant and report cutoff. Use the clock calculation to evaluate business time where required. Decide in advance whether a reopen restarts a cycle, continues the original obligation or follows another contractual rule.
Atlassian documents separate start, pause and stop conditions. Check the actual configuration and cycle history rather than assuming that a single resolved timestamp captures every obligation. SLA conditions documentation.
A completion cohort includes obligations completed during the reporting period, including older tickets. It answers how completed work performed. An opening cohort follows obligations started in the period, including those still open at cutoff. It answers what happened to that intake. A live snapshot shows all relevant open obligations at the cutoff and answers what still needs attention.
Never compare one month's completion cohort with the next month's opening cohort as though the percentages shared a denominator. Display cohort type, date basis and cutoff in the table heading. Retain older opening cohorts until they mature; otherwise late outcomes disappear when the calendar changes.
One account has 100 resolution cycles opened in September. Its agreed reporting policy excludes duplicate test submissions and cancellations made before any service obligation began. Ten cycles meet those documented exclusions. The remaining 90 are eligible.
| Eligible outcome at September 30 cutoff | Cycles |
|---|---|
| Completed within target | 60 |
| Completed beyond target | 10 |
| Still open and already beyond target | 8 |
| Still open and not yet due | 7 |
| Unknown because required timing evidence is missing | 5 |
| Eligible total | 90 |
Completed-cycle attainment is 60 divided by 70, or 85.7%. That number describes completed cycles only. The opening cohort also contains eight observed open breaches, seven pending outcomes and five unknown results.
If the policy defines a cutoff view that counts known passes and known breaches, its observed result is 60 divided by 78, or 76.9%. Label it as such. Do not call the seven pending cycles passes merely because they have not breached yet.
A completion-outcome bound for the full eligible opening cohort is 60/90 to 72/90, or 66.7%-80.0%, assuming all 12 pending or unknown outcomes eventually fail or pass respectively. This bound is a diagnostic under the stated policy, not a substitute for a contract's billing or credit calculation.
Keep a cycle-event table rather than overwriting the first resolution with the latest one. Suppose ticket T-04 closes within target, reopens and later breaches a new cycle. A cycle-level report contains one pass and one breach. A ticket-level policy might require both cycles to meet target, yielding one failed ticket. Both require a named rule; neither should be inferred after inspecting results.
Cancellation does not automatically mean exclusion. A customer cancelling after a missed response target may leave an already-observed breach. Require an exclusion reason, applicable policy, decision date and reviewer, and show excluded counts separately.
Check that source population equals excluded plus eligible. Check that eligible equals completed pass plus completed fail plus open breached plus open not-yet-due plus unknown. Reconcile opening backlog, new cycles, closed cycles and ending backlog separately if the report includes a stock view.
Display unknown coverage beside attainment. Missing evidence should not turn a result green or vanish from the denominator. The ticket-history workflow shows how to assemble these states from files.
Ask the service owner to approve the population before using the percentage in a customer review. An authorized sample and agreed definitions can support a scoped reporting conversation; a sample upload alone does not establish a complete live reporting service.
A completion-cohort report can focus on completed obligations, but it should be labeled and accompanied by open breached, pending and unknown counts.
That depends on the agreed observation unit and clock-cycle rules. Preserve cycle history and distinguish ticket-level from cycle-level results.