The Ninety-Eight Per Cent That Had to Show Its Working

The email arrives on the second Tuesday of the month, three days after the quarterly service review. The client’s contract manager has read the pack. The headline says the desk resolved 98% of tickets within target, and she would like to see how. Specifically: every ticket in the quarter with its opening, first-reply and resolution times; which service-level rule each ticket was held to; every pause on the clock and why; every reassignment and escalation; every ticket that was reopened; and written confirmation that nobody changed a timestamp, a priority or a category after the fact to bring a late ticket inside target. She would like it by Friday, because the service credit calculation depends on it.

Nothing in that list is unreasonable. A service-level figure is a claim about hundreds of individual promises, and the only way to test a claim like that is to go back to the promises. What turns the answer from awkward to routine is whether the desk’s system kept the evidence as a by-product of doing the work, or whether someone now has to reconstruct it from memory, inboxes and a spreadsheet that was last touched in August.

This post walks through that request line by line against what AWRA’s helpdesk actually records. If you want the basics first — why response and resolution are separate promises, and why a pause is what makes them fair — start with SLAs That Mean Something and Two Clocks, One Promise. Here the question is narrower and harder: when the figure is challenged, what makes it evidence rather than a number on a dashboard?

First, which ninety-eight per cent?

Before anyone exports a single ticket, settle the definition, because the system offers two figures that measure different things and a reviewer who receives the wrong one will find a discrepancy within the hour.

The dashboard figure is a health gauge for the people running the desk. The report is the one to put in a contract pack, because it is bounded by a period, it names its definition, and it counts tickets that have not finished yet — a quarter in which twenty overdue tickets are still open has not been 98% within target, however good the resolved ones look. If last quarter’s pack quoted the dashboard, say so in your reply and restate the figure from the report. Correcting your own definition before the client finds the difference is the cheapest credibility you will ever buy.

What every ticket carries without anyone typing it

The useful property of a helpdesk record is that most of what a reviewer wants is written by the system at the moment it happens, not entered by an agent afterwards.

• Opened. Stamped when the ticket is created, whether it came from the app, the public form, email or WhatsApp, and given a sequential reference.
• First reply. Stamped by the first reply the requester can see. An internal note does not stop the clock, because the requester has still heard nothing — the reasoning is in Making the First Real Reply the One That Counts.
• Resolved and closed. Stamped when the status moves, by the system rather than by a field on a form.
• Both due times. Calculated from the moment the ticket was opened, on the category’s own clock — real hours or working hours.
• The rule it was held to, shown on the ticket as, for example, “Urgent · Network category”, together with the promised minutes for response and resolution. Those minutes are kept on the ticket itself, so if the targets are tightened next quarter, this quarter’s tickets still show the promise they were actually made under.
• Reopens. Each time a resolved or closed ticket goes back into the queue, its reopen count rises and its resolution stamp is cleared.
• The conversation, every reply and note with its author and time, including the system notes left by escalation rules.

Every change made through the web screens is also written to the audit log: who acted, when, from which address, through which screen, and on which ticket. Audit entries cannot be deleted from anywhere in the product, and each is signed over the one before it, so an edited or missing entry shows up when the chain is verified — the argument for that is in An Audit Trail Nobody Can Delete.

What nobody can quietly change

The contract manager’s last request — confirm nobody moved anything — is really a question about which edits are possible at all. Here is the honest inventory, read from the code rather than from the brochure.

1. Timestamps are not form fields

   No screen and no API endpoint accepts an opening, first-reply, resolution or due time. The edit form takes a subject, priority, category, department and tags. The times are written by the system as the work happens, and there is nowhere to type over them.

2. A reopen keeps the original promise

   Reopening a ticket clears its resolution stamp but leaves its due time where it was. When it is resolved again, it is measured against the promise made when it was first opened — a ticket closed on time, reopened by an unhappy customer and fixed a week later counts as late.

3. A pause cannot rescue a ticket that was already late

   Waiting on the requester stops the resolution clock and gives back exactly the time that was left when it stopped. A ticket already past due when the agent asked their question gets nothing back, so moving it into waiting does not erase a miss.

4. Priority on a finished ticket is fixed for the figure

   Changing the priority of a resolved or closed ticket recalculates nothing. Re-dating a finished ticket would rewrite whether it met its target, so the recalculation runs only while the ticket is live.

5. Escalation only raises priority

   An escalation rule can make a ticket more urgent, never less, and every one that fires leaves a system note on the ticket saying what triggered it and what it did, plus an audit entry.

6. The conversation is append-only

   The helpdesk screens offer no way to edit or delete a reply or a note once posted, so the thread a reviewer reads is the thread the requester lived through.

A service-level figure is only as strong as the weakest edit someone could have made to the tickets underneath it. The question is not whether anyone did — it is whether you can show they could not, or show when they did.

Where the trail is thin, and how to cover it this quarter

Four things deserve candour, because the contract manager will find them if you do not, and each one has a practical workaround for this Friday as well as a proper fix.

Lowering the priority of a live ticket moves its due time. When the priority changes on an open ticket, both due times are recalculated from the moment it was opened, under the new rule. Usually this is triage doing its job — an “urgent” that turns out to be a password reset should be held to the password-reset promise. But it is also, mechanically, the move that turns an overdue urgent ticket into an on-time normal one. The audit log records that the ticket was edited, by whom and when; it records the edit, not the before and after values. For this quarter, pull every helpdesk edit entry in the period and compare it against the tickets whose current priority is lower than their opening one would suggest — a short list, in practice, and one worth explaining before you are asked.

Recategorising a finished ticket re-dates it. The finished-ticket lock described above covers priority. A change of category runs the full rule again, including the due times, whether or not the ticket is still open. If anyone tidied up categories on old tickets during the quarter, those tickets’ due times now reflect the new category. The audit log shows each of those edits with its date; any edit to a ticket after its resolution time is worth listing in the pack with its reason.

Pauses are recorded as they happen, not kept as a history. While a ticket is waiting on the requester, it carries the moment the pause began, and the status itself is the reason. Once the requester replies — which resumes the clock automatically, whether they answer in the portal or by email — the due time moves and the pause start is cleared. To list every pause for a ticket, read the conversation alongside the audit log’s status-change entries for it. That is reconstruction rather than retrieval, and for a large quarter it is the slowest part of the job.

Changes made in the mobile app reach the ticket but not yet the audit log. A status change or reassignment from the app updates the ticket, notifies the right people and stamps the right times — but the audit entry that the web screen would write is not written. Escalation rules record themselves either way. If your agents work mostly from phones, tell the reviewer which channel the desk uses, and treat the audit log as covering web activity only for this period.

Building the pack by Friday

Here is the order that gets a defensible answer out of the system with the least hand-work.

Exporting the audit log needs the settings-management permission, which is broader than most reviewers should hold; the reasoning and the workaround are in The Auditor Who Has to Be an Administrator. For a client review, export it yourself and hand over the file along with the verification result, rather than granting access.

Frequently asked questions