We're working on our flow and one major thing is we need to have someone "logged in" to a queue 24/7. Similar to like an office reception desk where we need someone to be at the desk answering the calls. Is there a way 1 or more agents can be "logged in" to a queue in some way?
On phones we do priority queues so reception puts their phone on DND (or logs off) and it'll skip them and go to a backup person and so on. I'm looking for something similar.
We're also trying to get metrics on how quickly someone who's ON is responding to tickets and such so maybe doing it on the ticket level is better?
I'm not sure if anything's built in as I haven't seen anything but still exploring
Hi Justin,
You can create a custom number field to store the time from when the ticket is created until say it is Assigned (Assignee field is populated). Then create a custom date/time field and call it something like Assigned. Then create an automation rule that populate the Assigned field when the work item is assigned (rule trigger based on Field Value Changed - assignee field).
Then do a re-fetch action in the rule. Then do an action for Edit work item and select the custom number field. Add smart values to do a diff between the created field and the new custom assigned field.
Assuming that the first thing the agent should do is assign the issue to themselves, this will fire the rule and you will know the amount of time it takes the agent to respond. Be sure put a check to see if the Assigned field is empty first when the issue gets assigned so it won't fire every time an issue is assigned to someone else. See example:
Use SLA on issues in JSM, then you will be able to see timing based on the goals set and the stop pause and start options.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Sure we do that now but it doesn't help us determine employee metrics.
Say Bob is handling the queue on Monday and Sally is on Tuesday. We want to know how long it takes Bob to touch a ticket vs Sally.
But we also need to know when Bob's on the queue and not on his lunch break or at the bathroom or whatever so we have Becky as a backup. We don't want Becky not responding to count against Bob.
The main goal isn't about knowing these metrics but we need Becky to know when to take the ticket in the queue when Bob's not there. We also need a way to visualize in Jira who's on so we can ping them when something comes in to help assist them.
Say Bob works 9-5 then Adam works 5-12, we need a way for Bob to know that Adam's online and signed into the queue so Bob can leave.
I assumed this was a simple thing that we didn't have setup. I figured everyone would be using this.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I know nobody doing ,this as this would work counter productive in my sense.
Measuring people on taking action, why, what would that deliver.
For me this is not a metric, as an issue can vary on complexity and the amount of issues in a period of time can vary.
To make sure that Adam takes over from Bob, this is a process, not an action a tool will fulfil.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
How do you know that someone's online and actively working on queues? How do employees know who else is available to handle inbound tickets and such?
If Bob is done for the day and doesn't check to make sure Adam is logged on how can we make sure tickets are being monitored?
Think about a chatbox on a website and we need to know if someone is online or not and who to assign the tickets to. If no one is online then it needs to show offline.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ask, talk to each other, a tool doesn't provide user interaction an communication for you.
Don't you have a handover process in place?
Adam needs to know if he has to pick up any of Bob's issues and what Bob has already done on these issues?
How will Adam otherwise know?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Isn't that the entire point of JSM? Bob should have assigned anything to Adam and notated every ticket. We want all ticket communication to be inside the ticket, not in JSM plus teams plus email plus personal texts.
There shouldn't need to be a handover process if JSM is functioning properly. Bob should know to logoff only when Adam is logged in.
Think about McDonalds drivethru, they just need to handover a headset to the employee taking over the shift. In JSM they should be able to do the same exact thing.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You mentioned you're looking to track how quickly someone who's ON is responding — have you considered using SLAs for this?
With SLA Time and Report (an app developed by our team), you can set up and track key SLA metrics like Time to First Response, even for 24/7 queues. This app can help you:
– Monitor how quickly your active agents are reacting to tickets
– Visualize SLA compliance in real-time (e.g., who’s exceeding, who’s meeting targets)
– Generate reports for performance review and accountability
The setup is flexible, you can create SLAs based on priority, time, agent groups, or even custom fields. Plus, the app offers visual indicators, so it’s easy to see at a glance if a ticket was responded to on time.
Have you worked with SLA tracking before in Jira? If not, I'd be happy to walk you through how this could fit into your current setup.
Let me know if you'd like to explore it further. I’ll be glad to help!
Regards!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I agreed with both @John Funk / @Marc - Devoteam original suggestions. It may be a business process training where your agents need to enforce manually - where When the existing agent assigned with issues, and he/she is not available, then he/she needs to re-assign the issues to other agents.
Once the original assignee is available again, then the current issue assigned agent will need to reassign the issues back to original assignee.
Another thing you can review is creating automation rule and implement "Round-robin" issue assignment - https://support.atlassian.com/jira/kb/jira-automation-rule-to-auto-assign-issues-based-on-role-or-group/
Lastly, you can also look into possible third party add-ons to support your need if possible - take a look at this Youtube video...
https://www.youtube.com/watch?v=ZUeJWgLHOgU
Hope this also helps.
Best, Joseph Chung Yin
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.