Plan requirement
| Subscription | Suite Professional or higher, Explore Professional or higher |
| Access | Admin |
In calendar hours yes, from the updates history dataset. In business hours, not for a custom field. Check that before you build.
Where does the answer live?
The Support - Updates history dataset records each change with a timestamp, so time in a value is the gap between the change that set it and the one that replaced it. The tickets dataset holds only the current value, so the question cannot be asked there.
Business hours is where it stops
Zendesk is explicit: there is no pre-built metric for the duration of a ticket field in business hours, and duration calculations for ticket fields in custom metrics are limited to calendar hours. Not a matter of extra effort: it is not available.
The business-hours duration metrics that do exist are fixed: First resolution time, Full resolution time and Requester wait time. They cover predefined ticket events, not your own field.
Why that matters
A ticket sitting in one value from Friday to Monday is 65 calendar hours and perhaps 1 business hour. Only the second is fair to your team, and it is the one you cannot calculate.
What should I use instead?
An SLA policy on the state you care about. It measures in business hours by design, alerts while it still matters rather than afterwards, and needs no formula.
Where the question is "are we leaving tickets in this state too long", that is not a workaround but the right tool: the reporting route was never going to answer it in business hours.
Fix the schedule before you need it
Business-hours measures are only as good as the schedule behind them, and there is no going back: the metrics capture the schedule as it stood at each event.
Comments
0 comments
Article is closed for comments.