Very simple, yet maybe important feature 
Make the time accounting input Message when edition a ticket a manatory field.
We want to force agents to enter time spent on a ticket.
This topic was automatically closed after 416 days. New replies are no longer allowed.
- What is your original issue/pain point you want to solve?
Zammad’s time accounting dialog is entirely optional today: even when an admin has configured a ticket selector so the dialog pops up on matching updates, an agent can always dismiss/cancel it without entering anything, and there is no setting anywhere that can require it. Zammad’s own documentation confirms this directly: “the time accounting dialog is not mandatory and can be canceled by your agents if needed. You cannot enforce time accounting.” As a result, tickets routinely end up closed with zero time logged, even in organizations where accounting for time is a hard requirement, not a nice-to-have.
- Which are one or two concrete situations where this problem hurts the most?
The clearest case is billing disputes with clients. When time tracking is used as the basis for invoicing, a ticket that gets closed without any time entry (because an agent dismissed the dialog, or simply didn’t trigger it) leaves no record of the work actually done. That forces the organization to either eat the cost of unbilled work, or reconstruct/estimate the time after the fact — which is exactly the kind of after-the-fact guess that clients push back on and that erodes trust in the invoice. The same gap also quietly degrades team and capacity reporting, since “time spent per ticket” metrics become unreliable wherever entries are missing.
- Why is it not solvable with the Zammad standard?
There is no standard mechanism to require time accounting. Admins can configure a ticket selector that decides when the time accounting dialog is shown and can set display units and activity types, but none of that changes the fact that the dialog itself is always cancelable — it is presentational, not enforceable. There is also no separate setting to block a ticket transition (e.g. to a closed state) when no time has been logged. In short, today’s time accounting is advisory only, by design, with no opt-in path to make it binding.
- What is your expectation/what do you want to achieve?
Add an admin-configurable option on the existing time-accounting ticket selector (the same place that already decides when the dialog appears) to mark that selector as mandatory. This should be opt-in and off by default, so organizations that are happy with today’s optional behavior see no change at all — it only becomes mandatory where an admin explicitly turns it on for a given selector.
When a selector is marked mandatory and its condition triggers the dialog, the agent should not be able to dismiss or cancel it without entering a valid time value; the update the agent is trying to make (e.g. adding the article, changing the ticket state) should not go through until a time entry has been provided. Once entered, everything else about time accounting continues to work exactly as it does today (the entry stays editable afterwards, reporting/export are unaffected, etc.).
If there is any more useful information, feel free to share it all (e.g.: mockup screenshots, if something is UI related, or the API URL/documentation URL for a service you need a connection to).
This request comes from a general product perspective (a recurring pain point around unenforceable time tracking) rather than one specific deployment.
Your Zammad environment:
- Average concurrent agent count: N/A — submitted as a generalized product request, not tied to one deployment
- Average tickets a day: N/A
- What roles/people are involved: Agents (who fill in the now-mandatory dialog) and Admins (who configure the ticket selector and toggle the mandatory option per selector)
Anything else which you think is useful to understand your use case:
One related, pre-existing limitation is worth flagging alongside this: the time accounting selector currently has to match the ticket’s state before closing for the dialog to appear at all, so an agent who both adds an article and closes the ticket in the same step can bypass the dialog entirely — independent of whether it’s mandatory. Making the dialog non-dismissable (this request) does not by itself fix that timing gap; it only guarantees that once the dialog does appear, it can’t be skipped. Whether these two issues should be solved together or separately is an open question I’d welcome input on — for a fully “mandatory” experience, both probably need to be addressed eventually, but this request is scoped to the dismissal problem specifically.
If you like that idea, please make sure to like the first article to bump that feature request.