{
  "id": 10626053,
  "title": "Our Tickets Closed Themselves Before the Night Shift Came Back",
  "url": "https://urgent.news/2026/09/29/our-tickets-closed-themselves-before-the-night-shift-came-back",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-29T06:27:48.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/serguey_shinder_4ab9b87b1/our-tickets-closed-themselves-before-the-night-shift-came-back-29p"
  },
  "original_language": "en",
  "account": "Our service desk tool automatically closes tickets when the requester has not replied for three working days. This setting, recommended by the supplier, functions well for employees at the head office. However, for depot staff who work in four shifts followed by four days off, the issue arose. A night shift supervisor who reported a scanner fault at three in the morning on her last shift would not receive a reply from our team until she returned five days later. By then, the ticket had been closed with a polite note stating we presumed the issue was resolved. She then created a new ticket, which would start at the back of the queue, or more often, she would borrow a scanner from the next bench.\n\nIn June, a regional manager informed me of several faults that had been reported multiple times by his sites. After investigating, we discovered that forty-three percent of tickets raised by shift workers in the previous year had been closed by the timer. In contrast, only nine percent of tickets from office staff faced the same fate. Our reports considered all of these instances as resolved within the target timeframe. The rule itself was not incorrect; it assumed that the person seeking assistance would be at work on the next working day, an assumption that held true for the personnel who configured it. However, nobody on my team had examined the depot rota, so nobody noticed that for half of our users, a three-day gap typically corresponds to a weekend.\n\nTo address this issue, the timer now counts the requester's shifts rather than the calendar, utilizing the rota feed from the workforce system. Consequently, a ticket will wait for three of her working days for a response, not ours. Where we have no rota, tickets from depot staff are directed to the site supervisor's queue before they can be closed. The result of the timer closing a ticket is now reported separately from the resolution outcome. Furthermore, any fault reopened within a fortnight is linked to the original ticket instead of creating a new one.\n\nAdditionally, the monthly service review now displays resolution rates by user group, eliminating the ability for depots to claim they are being well served by accident. Currently, timer closures for shift workers have decreased to approximately one ticket in eight. Silence from someone on a day off is not considered an answer. Our settings had been treating it as one for years.",
  "summary": "Our service desk tool closes a ticket automatically when the requester has not replied for three working days. It is the supplier's recommended setting, and for people at head office it works well. Most of our depot staff work four shifts on and four off. A night shift supervisor who reports a scanner fault at three in the morning on her last shift will not see our reply until she is back, five…",
  "key_points": [
    "Service desk tool automatically closes tickets after three working days without response",
    "Night shift supervisor's ticket closed prematurely, requiring new ticket creation",
    "Timer now counts requester's shifts instead of calendar days to address issue"
  ],
  "editors_take": "The change in ticket-closing rules levels the service experience for shift workers and office staff by accounting for differing work schedules, ending a hidden penalty that had skewed reported resolution rates.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}