Ronen Tamari

Thanks for your response and explanation, Barry Neary!

I understand the limitation, and also the reason behind it, but in reality, since agent changing their status to “online” is a manual action, by default, at the beginning of each day, one agent will be the first one to go online and then receive all the tickets up to capacity. 

This scenario could be easily prevented if there was a cooldown period that I could configure, or a ticket-assignment rate - for example, a condition that an agent can only get 1 new ticket every 15 min, 

This way, if all my agents are going online between 9:00 am and 9:30 am, the distribution will still be evened out, and not fill them up by the order of when they manually changed status to “online” 

I'm guessing that this could easily be a concern to any ZD consumer that has relatively smaller teams. 

Let me know if you have more questions or any suggested solutions. 

Barry Neary 

Based on this article, under “routing models” it is implies that Omni-Channel routing doesn't really do load-balancing, and this is indeed the behavior I see. 

In my case, when my first agent comes online in the morning, they immediately get as many tickets as possible until his “capacity rule” threshold is met. 

So even if load-balancing is a thing to some extent, and since we start each day with enough tickets that are unassigned, effectively, the first agent that turns their unified status to “online” is getting a disproportionate amount of tickets. 

What is your suggested solution here?
(assuming I would really want to refrain from simply lowering the capacity rule for all agents)

When using unified agent status, I see that when an agent shuts down their computer, they do automatically turn to be offline. 

I made sure my “idle time” is set to be off. 

Is there something I'm missing in my configuration in order to make sure my status is being kept and not bouncing back to “offline” automatically? 

Thanks for the feedback Scott!
It certainly does sound like it will solve my issue!

Is there a way to ensure that I will be notified if and when that becomes an available update/function/feature?

Hi Scott!

As a manager of a Support team in a B&B SaaS company, I try to divide my concerns into two kinds:

• Tickets that are caused by bugs in our platform (requires R&D fix) and are being put in "on-hold" status in ZD - and typically take longer, when the agent can't do much.
• Tickets that are only questions/misuse of the product that can be investigated and solved by the Support agents themselves. 

Since the agents on my team can impact mostly the second kind of tickets (not bugs - never "on-hold"), I measure them by "Agent Work Time", as the counter for that SLA metric is also being paused when tickets are in "on-hold" status. 

Currently, I can build a report (in ZD Explore) to analyze the "Agent Work Time", but I can't display it to the agents (in a View) to help them Prioritize correctly and be motivated correctly by the SLA I measure them on. 

Currently, when creating a View in Zendesk Support, the only optional SLA clock column is "Next SLA Breach" - and by default, it shows the "Requester Wait Time" clock (after the "First Reply" is sent).

It would be extremely helpful if the choice was given to the View creator which SLA metric to display in the View column they create. 

+1 for having admins be able to change agents' statuses.

This seems like a no-brainer and has been asked for a few years now.