Routing Delay for OCR | The place for Zendesk users to come together and share
Skip to main content
Feedback submitted

Routing Delay for OCR

Related products:Support
  • July 28, 2025
  • 2 replies
  • 12 views

Bobby11

Please give a quick overview of your product feature request or feedback and note who in your org is affected by this issue [ex. agents, admins, customers, etc.]. (2-3 sentences)

There should be a way to buffer new tickets from being assigned to Support agents (30 second delay, 1 minute, etc.,)

What problem do you see this solving? (1-2 sentences) 

Avoid overloading agents when they are the only agent available. 

When was the last time you were affected by this lack of functionality, or specific tool? What happened? How often does this problem occur and how does this impact your business? (3-4 sentences)

Every morning

Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)

No, agents are getting slammed with tickets when they first sign in, but sometimes the discrepency in sign in from other agents is only a few seconds (ie., one agent signs on at 9:00 AM, the second signs on at 9:01 AM). Agent 1 will have x number of tickets and agent 2 will have 0

What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)

Give us the ability to delay routing in some fashion

2 replies

Shawna James
  • Community Manager
  • July 29, 2025
Thank you for taking the time to provide us with your feedback. This has been logged for our PM team to review. For others who may be interested in this feature request, please add your support by upvoting this post and/or adding your use case to the comments below. Thank you again!
 

Keith16
  • August 12, 2025

Not having a delay between ticket assignment is problematic for multiple reasons.   One such example is when agents first login for the day, not all agents will log in at the exact same moment (generally +/- 2-3 minutes from the start of a shift).  Say each agent has an inbox capacity of 5 tickets and have no tickets existing tickets at  the start of a shift.  When they login, there are 5 Priority 1 tickets, 5 P2 Priority 2 tickets and 5 Priority 3 tickets in the queue, .  T

 

The way OCR works today is illustrated by a 3 agent example.  The first agent logs in at promptly 8:00am, the second at 8:01am, and the third at 8:01:09 AM. 

 

Agent-1, the first to login so will receive all 5 P1 tickets all at once.  When the second and third agents login milliseconds apart from each other around 8:01am.  Agent-2 will receives 3 P2 tickets before the Agent-3 longs in.  When Agent-3 logs in, (the round robin assignment logic will finally be evaluated), Agent-2 will be assigned the 1 remainin P2 ticket.  Next Agent 2 is assigned a P3 ticke

 

Timeline

  • Agent 1  (0/5 capacity) Logs in at 8:00:00
    • Assigned 5 P1 tickets within a fraction of a second. (inbox now at 5/5, all tickets are P1s)
  • Agent 2 logs in at 8:01:00.

    • Assigned 3 P2 tickets (inbox 3/5 tickets)

    Agent 3 logs in at 8:01:09

    • With two agents online,  for thirst time in this example multiple TSE are onling.
    • Assigned 1 P2 Ticket (inbox 1/5 tickets)

    Agent 2 

    • Assigned the remaining P2 ticket (4/5 tickets, owns 4 P2 tickets)

    Agent 3

    •  Assigned a P3 ticket (2/5 inbox capcity, 1 P2 and 1 P3)

    Agent 2 

    • Assigned a P3 ticket5/5 tickets (4 P2s, 1 P3)

    Agent 3 

    • Assigned remaining 3 P3 tickets (1P2 and 4 P3)

 

The problem here, hopefully is obvious

-  Agent 1 owns all 5 P1 tickets.

-  Agent 2 owns 4 P2 and one p3. 

-  Agent 3 owns 1 P2 and 4 P3.

 

This is not an equitable distribution of work due to rapid ticket assignment and round robin not functioning as designed until multiple agents are online and available.