Round Robin assignment

Super grateful for your feedback John. We are glad we did not invest the time to implement this, as it seems like you are going for our exact use-case and it doesn't sound like it works. @barry14 please forward that to your team. I am pretty sure most people would like a  configurable logic like "if agent has 5 open tickets, assign 5 more" I thought this is what was being developed here, the way John describes it, it definitely is not? When can we expect an upgrade on this?

Hi, the logic is:

1) Which agents has the highest spare capacity (rather than the one with the least open) (i.e. attempt to load balance first)

2) If more than one have the highest spare capacity, then give it to the agent who has not being assigned a support ticket/message in the longest time

We have the ability tp define you own routing logic on the roadmap....

>>> It still will give one agent 7 tickets, the other 2 when they have the same number of OPEN tickets in each of their assigned queues.

>>> I am pretty sure most people would like a  configurable logic like "if agent has 5 open tickets, assign 5 more" I thought this is what was being developed here

In 2013 I began following this thread only because I had developed a simple, but effective Round-Robin system in 2011 for a client using Google Apps Script. That app was really productive for my client's team and I believe they even openly shared it in 2015.

Here we are 9 years, 11 months, and 13 days later and it appears the target objective has not been reached. Based on the thread, it doesn't appear that it's even close to being ideally suitable or close to matching customer expectations.

You realize that since this thread began, a sizeable amount of American history has occurred. Couples have married. They've conceived babies, raised them, and these kids are now just a few years from middle-school. Tesla Reinvented the automobile. SpaceX reliably lands reusable rocks backwards. And StarLink has launched more than 3,500 satellites. GPT-3 has a multi-trillion parameter AI model capable of writing complete articles and answering almost any question. All while Zendesk tried to get round-robin assignments to work. Unbelievable.

I have a very long and storied tech career starting with LapLink (which was really a 1982 project to move data from the Space Shuttle computers to IBM desktops), and then QuickSite in the 90's, MyST in the 2000's, and real-time analytics, and CyberLandr today. And despite this long tech career, this round-robin thread has been alive for 25% of my entire time in tech. I eagerly watch for messages hoping to read the final one. The message that signal this "feature" now exists and customers are thrilled to use it to create hyper-productivity for their support teams.

>>> We have the ability to define you own routing logic on the roadmap....

Really? I thought that was the essence of the roadmap in 2013.

If the right mix of tech and process logic didn't leap into the hands of customers within one year, ten more years is not likely to make it happen. Besides, the nature and topography of this problem has now dramatically changed because AI is how it should be solved. If there isn't a healthy dose of machine learning in the architecture of this feature, it should be scrapped.

Just sayin' ...

I couldn't agree more, and as a result of this tardiness approach to their customers, Zendesk is very low down on my evaluation for a supporting tool next year. 

Thanks @barry14 those are helpful logic tidbits to know, and I'll make sure I add it to our internal documentation on how our setup should work.

Well, as of today we are disabling Omnichannel routing.

It keeps picking just two agents and going back and forth between them, even when other agents are online and have capacity. I set capacity at 10 for all agents, and it's not assigning tickets to agents with 1 open ticket, but choosing these two agents over and over, who have 0 open and 2 open, respectively. 

We really need it to distribute tickets evenly, and it absolutely does not do that. 

We're also finding that ZD sets folks offline for no reason - even while they're actively working. 

We also submitted a support ticket outlining these issues on Tuesday, here it is Friday and no one has even responded. 

So, disabling Omnichannel as it is just not ready. 

We faced a similar issue with uneven distribution with respect to agents and ticket channels (a few of them are not even supported) while we were testing the EAP program. We escalated multiple times at different channels with no proper response. Agents handling support tickets have no clue about the setup. We had to deactivate it then, and it seems it's still the same after public release, are our feedback even heard? What is the point of having EAP if you do not wish to hear feedback?

Hi @john mole: Have you created a ticket with our support in relation to your issue? If so, could you do so I and the team can try and figure out what the issue is?

@kulin @john50 has either of you given this omnichannel routing/round robin approach another try? It's been 3 months since I looked into this, and I am wpndering if anyone here with a similar use-case like us had by now implemented it/in use succesfully? 

@barry14 circling back to the statement ">>> We have the ability to define you own routing logic on the roadmap...." any news there? We definitely need to be able to define our own routing logic. So if this is now available we would be happy to give it a try soon too. Haven't been able to find any news on this in recent product-releases 

Last Updated article I found that mentions this is https://support.zendesk.com/hc/en-us/articles/4408831496730-Can-Zendesk-Support-equally-distribute-tickets-amongst-agents-or-groups- > from Jan2023 saying this feature is not possible in Zendesk directly without the use of an external app still - can you confirm what the status is here? 

Hi @retourenstation

The current omnichannel routing solution we have works this way:

assigns tickets to agents within a group first based on load balancing (i.e. which agents have the highest spare capacity - assign them tickets first) and then by round robin (once agents all have the same spare capacity, assign tickets to whichever agents havent been assigned tickets in the longest time).

In the future we do have plans to enable you to customize your routing methodolgy, but that is not on the plans for 2023. Is there a specific way you would want routing to work? Perhaps there may be a workaround....

Hi all

Omnichannel routing was released Oct 2022 and we have just added Skill Based Routing to that release.

Barry

Hi! Any updates on the round robin feature?

Hi Elisa, 

Currently the routing logic is still as described here

Could you describe how you would wish it to work?

Barry

Any News?

Hi Barry!

I'm not Elisa, but I think that the idea of Round Robin is to play tickets for each agent in turn as long as they reach full capacity. When the first round is completed the next round can start with those agents who still have spare capacity left. If others get free capacity, before the round is completed, they are back again when the the next round starts. It does not need to be more complicated that that. 

Now this current way to push the tickets to person with the most capacity causes multiple issues for us too. Our workload varies a lot, so we have spare capacity "for the rainy day". Now when Zendesk tries to fill this spare capacity up, other agents, with smaller capacities can't get tickets at all.

Hi Elisa,

We have two things that we are targetting in Q2 2024 that may help you:

1) % spare capacity: calculating spare capacity on a % basis rather than as a number. e.g. one agent has max capacity of 10, the other 2. If the former agent has 8 assigned tickets and the latter 1, then the former agent today has a higher spare capacity (2 vs. 1). However % spare capacity option if turned on will have the latter agent having 50% spare capacity and the former only 20% , so the former will get the next ticket

2) Round robin: this option when enabled will not check who has the highest spare capacity but instead will use a round robin methodology, i.e. whoever has not been assigned a ticket in the longest time will be assigned the next ticket. It will respect the max capacity of an agent though (which is in line with what you described above). However, it will not implement the ability to define the max capacity of an agent in terms of number of tickets they can be assigned per hour or per day (as the Round Robin app does). This is a more complex change.

Barry

Thank you, Barry!

Barry, why is this post marked as Complete, when round-robin assignment is not supported via the current omni-channel routing. Please mark this post as Incomplete again.

Changed back to Planned

Hi there @barry14 I would just like to follow up on the release of option 2 here in your post:

2) Round robin: this option when enabled will not check who has the highest spare capacity but instead will use a round robin methodology, i.e. whoever has not been assigned a ticket in the longest time will be assigned the next ticket. It will respect the max capacity of an agent though (which is in line with what you described above). However, it will not implement the ability to define the max capacity of an agent in terms of number of tickets they can be assigned per hour or per day (as the Round Robin app does). This is a more complex change.

Is this still on course and if so, are we closer to getting an exact ET for this release?

Hi Jean

Work will start on this mid Q3, I am awaiting an effort estimate so cannot give a specific GA date yet

When can we get round robin enabled for omnichannel routing? We did some testing with our team this week and capacity routing does not work for us. The support leaders specifically ask for round robin as it's a more fair approach to ticket assignment. 

Hi

We have it on our roadmap to implement round robin  - awaiting confirmation of expected release date

Hi @barry14,

I would love to also ignore tickets based on tier for capacity. Our current setup is hard to use the omnichannel as designed because the only thing i want to count for capacity is tickets created and in certain tier. 

Best,

Any news on this? We'd love to start using round-robin assignement (based on # of open ticket/agent limits) but this feed has me question wether what is currently possible in Zendesk is working for anyone? Don't want to waste my time if truth is: round robin is not an option yet :) Appreciate any feedback here.