On call and RR rules when shifts are overlaping

[Alexandra Bolchi]

How can I efficiently create an on-call schedule utilizing a round-robin rule to ensure fair distribution of tickets, particularly when shifts overlap? What strategies or tools could facilitate this process effectively?

The exact situation we are facing is: we have a 24hour coverage provided by 3 teams. We have set up the teams and the respective on calls, however we have some overlaps between the 3 schedules, hence we cannot get the tickets auto assigned, that is what we understood from support.

What we want to accomplish: Tickets to be auto assigned to team members as per their respective shifts, in turns (round robin)

How can we automate the assignment of tickets to team members based on their respective shifts, adhering to a round-robin distribution approach? Particularly, how can we ensure that tickets are evenly distributed among team members even when their shifts overlap?

Any idea how to fix this error?

Thank you in advance for any recommendations. 

[Jaime Capitel _resolution_]

Thanks @Tom Russell! That makes sense with what I've experienced... alerts keep being sent to the same individual on call, even within the same team.

[Tom Russell]

A round-robin distribution implies keeping state from one alert to the the next; something not easily done with Opsgenie. Another way that would (theoretically) give an even distribution would be to route randomly between the teams during the overlap period.

I'm not sure how your tickets are coming in, but if you have a date field accessible, you could:

• Create an alert policy to pull the last seconds digit from the date field and store it in a key-value field. This assumes that alerts come in randomly, an assumption that may not be valid. Maybe the 10s digit of the seconds field?
• Create routing policies that would only be in effect during the overlap, and would match the values in that field:
  • Policy for team 1 - field is 0-4
  • Policy for team 2 - field is 5-9

[Jaime Capitel _resolution_]

I'm sorry @Tom Russell sort of eavesdropping here...

What do you mean with "keeping state from one alert to the next"?

[Tom Russell]

@Jaime Capitel _resolution_ by "keeping state" I mean remembering who the last alert went to and sending the next one to the other team.