-
What is your original issue/pain point you want to solve?
There is currently no way for an individual agent to set their own default for the “Pending till” date and time, per status. This isn’t an issue in the current UI, where the default time is always 8:00. The (still rarely used) beta UI instead defaults to the current time, which has its own good reasons and its own fans. The result is two competing conventions (fixed 8:00 vs. “now”) with no way for an agent to pick the one that matches their own habit. As more agents move to the beta UI, they’ll be stuck with whichever convention that UI uses, and have to manually correct the field every time it doesn’t match their habit. -
Which are one or two concrete situations where this problem hurts the most?
Agents who work through high ticket volumes (e.g. around 100 tickets a day), call customers, and set a reminder to try again the next day, are used to having their “daily dose” of reminder tickets ready first thing in the morning — a habit built on the current UI’s 8:00 default. Once they move to the beta UI, which defaults to “now,” they have to manually change the time on every single reminder they set, which adds up across dozens of tickets a day. At the same time, other agents actively prefer the “now” default because it spreads their reminders out over the day instead of dumping them all at once in the morning — so neither convention should simply replace the other.
A related case: some agents have a strong personal habit of always pushing “pending close” out by a fixed number of days (e.g. always +3 days), and currently have to select that manually every time as well. -
Why is it not solvable with the Zammad standard?
The default behavior for “Pending till” is a single, global convention baked into whichever UI is in use (8:00 in the current UI, current time in the beta UI). There is no setting — for admins or for agents themselves — that lets an individual agent choose their own default per status. Since agent habits and preferences genuinely differ (morning-batch vs. spread-over-the-day, or a fixed number of days for pending close), a single global default can’t satisfy everyone, and there’s no per-agent override available today. -
What is your expectation/what do you want to achieve?
Let each agent configure, in their own profile/preferences, a default for “Pending till” per pending status (Pending reminder, Pending close, and any custom pending states), made up of two independent parts:
- Date default: “today” vs. “+X days” (agent-chosen number of days)
- Time default: “current time (now)” vs. a fixed, self-selected clock time (e.g. 8:00)
When an agent switches a ticket to that status, “Pending till” is pre-filled from their personal defaults for that status, while remaining fully editable on a per-ticket basis.
Related existing request: GitHub issue #143, “Allow admins to set optional default pending times for pending states” (Allow admins to set optional default pending times for pending states · Issue #143 · zammad/zammad · GitHub), asks for admin-configured defaults per pending state. This request is deliberately scoped differently — purely per-agent, per-status personalization, not an admin-wide setting — since the core problem is that agents’ own habits differ, not that the organization needs one enforced default. The two could potentially share an implementation (admin default + agent override), but the ask here is specifically the per-agent layer.
Your Zammad environment:
- Average concurrent agent count: N/A — submitted from a general product perspective, not tied to one specific instance
- Average tickets a day: N/A — see above (the ~100 tickets/day figure in point 2 is illustrative of the affected workflow, not a specific instance’s volume)
- What roles/people are involved: Agents (this is a personal, per-agent preference; no admin involvement needed for the feature itself)
Anything else which you think is useful to understand your use case:
The two current “competing standards” — 8:00 fixed (current UI) and current time (beta UI) — both have legitimate use cases and their own supporters. This request isn’t about picking a winner between them, but about making both available as selectable per-agent defaults, so agents don’t have to fight their tooling to keep a habit that works for them — including as the beta UI becomes more widely adopted.