Skip to content
Workspacebeamcore

Journal

What a first-response clock should actually start from

11 March 2026 Helen Cartwright
Person in a quiet office reviewing papers near a window
Person in a quiet office reviewing papers near a window

Most extracts we see treat ‘date opened’ as the start of first response. That is convenient. It is also often wrong. If a user raises a ticket at 22:14 on a desk that advertises cover until 17:30, starting the clock at 22:14 will show a breach that no one on the late rota could have prevented.

Desks that publish a first-response target usually mean ‘from the next minute of advertised cover’. That needs two fields, not one: the timestamp the record was created, and a calendar of when the desk is open. Without the calendar, a pretty chart of medians will punish every overnight password reset.

University desks and council contact centres often run different hours for public phones and for staff email. If both land in the same queue, the extract has to carry a channel flag. Mixing them and then drawing a single first-response line is how a manager ends up defending a figure nobody on the floor recognises.

When we draw a quarterly pack we ask for the advertised hours in writing, including lunch closure if the phones really do go to voicemail. We then start the clock at the later of ‘record created’ and ‘next opening minute’. If your system cannot export opening hours, we still draw the chart — but the covering note will say the clock is calendar-blind.

A mild test: pick ten tickets from a Sunday evening and see whether your current report already treats them as late on Monday morning. If it does not, your first-response chart is telling a story the rota cannot live with.

Back to the journal