A support ticket closed twice during one week can become two resolved cases in a poorly defined report. That may be a valid count of closure events, but it is not a count of distinct tickets. Reopening also changes the ending backlog, so subtracting every closure event without accounting for reopened states can make the weekly report look better than the underlying records.
The proposed procedure below defines and reconciles those measures before AI writes commentary. It does not prescribe a universal support performance target. The reporting owner chooses the metrics and their business meaning. The practical output is a ticket/event reporting contract that prevents one label from hiding different calculations.
Define tickets, transitions and cut-off states separately
Use a stable ticket ID for the case. Retain event IDs for accepted status changes, with event time, source and sequence information where available. A ticket can have several events without becoming several customer cases. Repeated processing of one event should not create another transition.
Define the reporting window and timezone. State whether end-state metrics reflect the accepted system state at the cut-off or a later reconstructed snapshot. Late corrections can change the reconstruction, so preserve the version used for each issued report. Receipt time and actual transition time are different fields.
Agree terms such as distinct tickets closed at least once, closure events, tickets closed at cut-off and reopening events. These measures can all be useful, but they are not interchangeable. A report headline saying resolved tickets must identify which accepted definition it uses.
Calculate from the accepted event history
Order accepted events using the system's reliable sequence and timestamp rules. Equal or missing timestamps can require a source-version or sequence check. Do not let the language model choose a convenient ordering. If the accepted state cannot be reconstructed, mark the affected ticket unresolved for reporting.
Exclude confirmed repeated imports under the approved event identity rule while preserving their processing history. Similar events with different established identities may represent genuine repeated transitions. Staff should resolve uncertainty rather than suppressing every repeated close label.
Source: Google Sheets batch updates describes grouped spreadsheet updates and separate cell-value operations. It can support a reporting integration, but it does not define ticket measures or prove event histories are complete. The actual calculations and source snapshot controls require implementation and review.
Reconcile the ending population and explain differences
Check beginning and ending states against accepted ticket records. If the reporting contract uses event transitions, distinguish closures and reopenings that change the relevant backlog from administrative edits that do not. Record new tickets, transferred scope and excluded states under explicit rules.
A state reconciliation can use opening open tickets, accepted new open tickets, relevant closures and relevant reopenings where the simplified rules apply. Real systems may need additional transitions. The information owner should specify them rather than borrowing a formula that ignores transfers or merged cases.
Compare event-derived results with the accepted cut-off snapshot and show any difference. A total that matches can still contain wrong ticket membership, so inspect stable IDs and exclusions too. Missing history must remain missing; do not generate a plausible reopening event to make the balance work.
Reusable reopened-ticket reporting contract
Use this proposed contract before a weekly support report is generated.
| Measure | Proposed definition | Required evidence |
|---|---|---|
| Distinct tickets in scope | Unique accepted ticket IDs meeting inclusion rules | Ticket population and scope version |
| Closure events | Accepted transitions into the defined closed state during the window | Event IDs, ordering and timestamps |
| Distinct tickets closed at least once | Unique ticket IDs with one or more accepted closure events | Membership list, not event count |
| Reopening events | Accepted transitions from the defined closed state into an open state | Relevant event references |
| Closed at cut-off | Tickets whose accepted cut-off state is closed | Snapshot or verified reconstruction |
| Open at cut-off | Tickets whose accepted cut-off state is open | Snapshot/reconciliation and exclusions |
Reporting record: [Window/timezone, source extraction time, definition version, accepted event list, cut-off snapshot and calculation version]
Exceptions: [Missing event, conflicting ordering, repeated import, transferred ticket or late correction; affected IDs and owner]
Narrative rule: Use each accepted measure by its exact meaning. Do not equate closure events with unique cases resolved, and do not describe a reopened case as permanently resolved unless the accepted cut-off evidence supports that statement.
Review decision: [Owner accepts totals and wording, requests correction or holds the affected measure]
The completion check is that the distinct-ticket measures reconcile to membership lists, event measures reconcile to accepted transitions and the end-state measures agree with the accepted snapshot or an explained limitation.
Work through a ticket closed twice
Consider a hypothetical simplified week beginning with three open tickets: A, B and C. Ticket A closes, reopens and closes again. Ticket B closes once. Ticket C stays open. Assume no new tickets, transfers or other state changes.
There are three closure events and one reopening event. Two distinct tickets closed at least once: A and B. At the cut-off, two tickets are closed and one remains open. The simplified backlog reconciliation is three opening open tickets minus three relevant closures plus one reopening, leaving one open ticket. Reporting three unique tickets resolved would be incorrect.
Now suppose A's second closure event is imported twice with the same established event ID. The accepted event set counts that transition once, so the totals do not change. If another genuine reopening follows it before the cut-off, A becomes open at cut-off while still having been closed at least once. The two measures remain different and the narrative must preserve that distinction.
An incomplete event history creates another case. If A's accepted cut-off state is open but the supplied events show only a closure, the report flags missing or conflicting evidence. It should not assume a reopening happened at a guessed time. The owner retrieves the source history or accepts a clearly limited measure.
Give AI accepted measures and their definitions
Source: OpenAI Structured Outputs describes schema-constrained responses. A proposed narrative schema can require metric IDs, values, definition versions and unresolved evidence. Schema shape does not validate counts or prevent a misleading paraphrase. Compare every reported number and term with the accepted contract.
Source: OpenAI function calling distinguishes model requests from application execution. A reporting lookup should return only accepted measures and limitations. Preparing commentary should not let the model change ticket states or definitions to improve the weekly result.
Evaluate with fixtures covering repeated closures, reopened-at-cut-off cases, duplicate imports, late events, transfers and missing history. Check both arithmetic and wording. A report that calculates correctly but calls closure events unique resolutions still fails the meaning check. Record actual reviewer corrections before claiming clearer or more efficient reporting.
Questions about reopened ticket counts
Is counting every closure event always wrong?
No. It is a valid event measure when explicitly defined and labelled that way. The error is presenting it as a count of distinct tickets or durable customer resolutions. Keep the accepted meaning and membership evidence with the figure so readers know what it represents.
Should reopening remove the earlier closure from history?
No. Preserve the accepted event sequence. Reopening changes later state and may affect a different measure, but it does not erase that an earlier closure event occurred. Use the reporting contract to decide which count or state belongs in each section.
What if the ticket system and export disagree at cut-off?
Hold the affected measure or label the accepted limitation after owner review. Compare event coverage, extraction times, scope and late corrections. Do not let AI choose the more favourable total or create missing events. Preserve the source snapshots and the recorded reconciliation decision.
If your business needs help defining this process, explore Workflow automation, the wider AI automation services, and our custom-agent workflow guide. The agents and automation comparison and custom AI agent glossary explain the terms. To discuss your records and approval rules, get in touch.