| Announced on | Rollout starts | Rollout ends |
|---|---|---|
| January 17, 2023 | January 17, 2023 | January 23, 2023 |
We're excited to announce an enhancement to unified agent statuses: idle timeout.
What's changing?
With idle timeout, you can cause inactive agents to be set to Away or Offline after an idle period of your choosing. Once enabled, if Zendesk doesn't detect interactions from an agent for the defined idle threshold, the agent is briefly shown an alert and then their status is automatically changed.
Previously, agents had to manually change their status to Away or Offline before stepping away from their desk. If they forgot to change their status, work would continue to be routed to them even though they weren't actually available.
For more information, see Enabling idle timeout for unified agent statuses.
Why is Zendesk making this change?
One of the most requested enhancements for unified agent statuses was a way to automatically change an agent's status if they become unavailable. The idle timeout setting does just that, helping to ensure agents are available and active when work is routed to them. We also made sure to provide granular controls over the idle timeout settings so admins can make it work for their unique workflows.
What do I need to do?
No action is required. This feature is available to everyone, but to use it you must enable the Zendesk Agent Workspace and omnichannel routing. Requirements for the Agent Workspace and omnichannel routing apply.
10 Comments
Now THIS is really great! We can look into using agent statuses again because of this!
This is a gamechanger! Automatic Idle was a BIG requirement for us to move into the new Omnichannel routing.
Looking forward to having an API Endpoint for Agent Statuses/Availabilities and enhanced Explore reporting on agent statuses, which are the 2 other Must Haves.
It might be good to make it more clear that this is not available to anyone using Live Chat, as Omnichannel Routing is not a feature that can be turned on, if you use Live Chat.
@CJ Johnson, this seems quite obvious for me I guess..
You would think, Julio Cesar but since I have had to argue with multiple Zendesk staff members as well as community members about this, in multiple threads on the site, who insist I can use features that require Omnichannel routing (or routing itself even), it apparently isn't. I am already anticipating being linked to this article and told "It says everyone" when I ask for this to be made available to the rest of the customer base, so I'm just trying to cover my bases. :)
Hi CJ Johnson. Thanks for your feedback. I added links to the Agent Workspace and omnichannel routing articles that outline their respective requirements and limitations and clarified that all requirements for enabling those features apply to this feature as well. I hope that helps.
We don't use (or like) the agent workspace. Is there a way to achieve this with Zendesk Talk? If someone is away that it sets their Talk status to away?
this is unfortunately not possible.
The feature is only available with Agent Workspace and omnichannel routing.
The Agent would have to set themselves as "Away".
You are more then welcome, to leave Feedback about it in our Community.
Anne Ronalter Zendesk is closing out the old requests, and marking new ones"answered" when the community posts the very same request Josh has as Feedback: https://support.zendesk.com/hc/en-us/community/posts/5326421094938-Repost-Feature-Request-Give-Admins-Ability-to-Change-Agent-Status-
I'm very frustrated to see others being told to do the same thing I did that resulted in the request being ignored and having my issue marked "answered". How are we supposed to request things like this? It seems like teams in Zendesk are not in agreement on how feature requests should work, and customers are getting stuck in loops of being told to do a thing to request a feature, and then having that request closed out and ignored.
Hi CJ -
Thanks for bringing this issue with our process to our attention. We'll look into what's going on. In general, feature requests should never be marked as "Answered," That tag is reserved for posts where there is a question and it receives a response.
However, with our efforts to increase engagement from our product managers across the company in the community, it makes process control a bit more difficult and sometimes people are unclear on what they're supposed to do. People aren't always perfect in the execution of large-scale communications.
Please sign in to leave a comment.