A tenant reports a leak at nine in the morning. Someone picks it up within the hour, a contractor is out by lunch, and the ticket is marked resolved mid-afternoon. Three days later, once the tenant has confirmed it is fine, the ticket is closed. Your end-of-month report should show that one as resolved in six hours, on target, every month from now on.
That is what Beacon, our helpdesk system, does. Each priority carries a first-response target and a resolution target. The ticket records the moment each was met, and the report reads those moments back. Open the report in March and the leak from October still says six hours.
Two clocks, and the moment each one stops
Beacon gives every priority its own pair of targets. An urgent ticket might need a first response within an hour and a fix within four. A low one might allow a day and a week. On the ticket itself you see both clocks, each marked on track, met or breached.
Two moments stop them. The first response clock stops when someone on the team replies to the person who raised the ticket, not when an internal note is added. The resolution clock stops when the ticket is moved to Resolved. That timestamp is written onto the ticket and stays there.
Closing is a separate, later step. A ticket goes Resolved when the work is done and Closed once the requester is happy or enough time has passed. The two statuses exist so that “we fixed it” and “we are finished with it” can be different moments, which in a property or operations team they usually are.
The step that wiped the record
While Beacon was still pre-launch, on test data, a ticket that had been resolved in ninety minutes showed as breached. We looked at the report two months after the ticket closed, and the 90-minute fix read as 60 days late.
The cause was one line of logic. When a ticket is reopened, moving it back out of Resolved, the system clears the resolved time so a fresh fix gets a fresh stamp. That is correct. But the rule was written as “clear the time whenever a ticket leaves Resolved”, and Closed is also a move out of Resolved. So every ticket that completed its normal lifecycle lost its resolved time at the last step.
With no resolved time on record, the breach check fell back to asking a different question: has the deadline passed yet? For a closed ticket, eventually the answer is always yes. Give the report a few weeks and every closed ticket is late, including the ones fixed in an hour.
The second thing that was nearly right
The dashboard had a tile labelled “Open tickets past their SLA”. The number on it was correct. What it counted was every ticket not yet Closed, which includes Resolved ones. A resolved ticket that had breached was still sitting in the “open” count after the fix had gone in, because nobody had pressed Closed yet.
Nothing about that number was wrong. The word “open” was. A manager reading it would assume seven tickets needed attention when four were already dealt with.
What changed
Both fixes were small. That is the point: a service-level report is a lot of small decisions about when a clock starts, when it stops and what each number is called, and any one of them being slightly off is enough.
- Resolved time is kept through Closed. It is only cleared when a ticket genuinely reopens, by moving backwards out of Resolved. A closed ticket keeps the record of when it was fixed for as long as it exists.
- The breach check uses the record, not the clock on the wall. If a ticket has a resolved time, the question is “was that before the deadline?” and the answer never changes afterwards.
- The tile says what it counts. “Not yet closed” rather than “open”, so a manager knows the figure includes work that is done but not signed off.
- Each fix has a test that fails without it. The first one was reproduced on a running copy of the system before it was fixed, so we knew the report could be made to lie and then knew it couldn’t.
Why the record matters more than the number
A service-level figure gets used in conversations that matter: a board pack, a contract review with a managing agent, a tenant complaint. The moment someone asks “which tickets?” the figure has to break down into a list, and every line on the list has to hold up when you open the ticket.
A report that drifts, where a good month quietly becomes a bad one as time passes, is worse than no report. People stop trusting it, then stop looking at it, and the targets it was meant to protect stop meaning anything. The fix for that isn’t a better chart. It is making sure the system writes down the moment that matters and never overwrites it by accident.
Every line checkable against its ticket
That is the standard we build to: any figure on a report should be traceable back to a ticket, and the ticket should still say the same thing a year later. Beacon’s SLA report now meets it. The resolved time stays, the breach check reads it, and the tile is honest about what it is counting.
Ready to see a helpdesk whose report you can check?
Beacon is a working system you can try on demo data at beacon.moonfive.co.uk. If your team tracks response times in a spreadsheet, or in a tool whose numbers nobody quite believes, it is a starting point we adapt to your own statuses, priorities and targets.