Sodium release for helpdesk: related tickets, attachments, changed time management, etc.
-
@quixoticjeremy Absolutely an optional flag to auto escalate a ticket.
As for the escalation notes provided, they should only be visible to the IT department and not sent out to the person who created the ticket.
-
@dustinb3403 said in Sodium release for helpdesk: related tickets, attachments, changed time management, etc.:
@quixoticjeremy Absolutely an optional flag to auto escalate a ticket.
As for the escalation notes provided, they should only be visible to the IT department and not sent out to the person who created the ticket.
Why not have this configurable as well. Could might light a fire under the responsible user?
-
Providing the ability to assign a ticket to a team member is also a requirement. This way a manager can track who is completing what, and when someone was assigned to the ticket.
Even if by Email only, they are the owner of the ticket. Of course the ability to reassign a ticket has to be there as well.
-
@quixoticjeremy said in Sodium release for helpdesk: related tickets, attachments, changed time management, etc.:
@dustinb3403 said in Sodium release for helpdesk: related tickets, attachments, changed time management, etc.:
@quixoticjeremy Absolutely an optional flag to auto escalate a ticket.
As for the escalation notes provided, they should only be visible to the IT department and not sent out to the person who created the ticket.
Why not have this configurable as well. Could might light a fire under the responsible user?
I was thinking optional per site, not per ticket. IE. the IT department wants the tickets to auto escalate because of RPO/RTO requirements.
If a ticket is open for days, it causes them to fall out of compliance.
But another IT department doesn't have such a requirement.
-
@dustinb3403 said in Sodium release for helpdesk: related tickets, attachments, changed time management, etc.:
Providing the ability to assign a ticket to a team member is also a requirement. This way a manager can track who is completing what, and when someone was assigned to the ticket.
Even if by Email only, they are the owner of the ticket. Of course the ability to reassign a ticket has to be there as well.
Reassigning tickets is already do able. Assigning to a team is on the project list already.
-
Wooh that just gave me another idea. Of providing an RPO/RTO field that is internal to the department for tracking purposes so a department can track their overall performance and improve / adjust their BIA accordingly.
RTO/RPO: Printers can be down for 3 days as we have others
Actual recovery time: 20 minutes
Recommendation based on Ticket Average: Reduce RTO/RPO -
@dustinb3403 said in Sodium release for helpdesk: related tickets, attachments, changed time management, etc.:
Wooh that just gave me another idea. Of providing an RPO/RTO field that is internal to the department for tracking purposes so a department can track their overall performance and improve / adjust their BIA accordingly.
RTO/RPO: Printers can be down for 3 days as we have others
Actual recovery time: 20 minutes
Recommendation based on Ticket Average: Reduce RTO/RPONow that's a cool feature but likely going to come in down the road a ways.
-
The general idea behind the RTO/RPO is once a business has this, they can actively track their performance of being able to resolve problems within their objectives.
Might be overkill and a lot of processing for it. But they'd put in their general objectives in Minutes, Hours, Days etc and then assign a ticket to it that RTO/RPO and proceed to fix the issue.
-
@dustinb3403 said in Sodium release for helpdesk: related tickets, attachments, changed time management, etc.:
The general idea behind the RTO/RPO is once a business has this, they can actively track their performance of being able to resolve problems within their objectives.
Might be overkill and a lot of processing for it. But they'd put in their general objectives in Minutes, Hours, Days etc and then assign a ticket to it that RTO/RPO and proceed to fix the issue.
Which makes perfect sense, but this definitely comes in down the line a bit in terms of priority compared to other functionality. Very useful but ultimately not as important as core helpdesk functionality to begin with.
-
@quixoticjeremy Thanks for confirming, I have signed up and I will take a look around.
-
@stuartjordan said in Sodium release for helpdesk: related tickets, attachments, changed time management, etc.:
@quixoticjeremy Thanks for confirming, I have signed up and I will take a look around.
Awesome, glad to hear! It's a fresh/very early project so we really do appreciate any input. Now really is the time to have your voice heard so that we can make this something that you'll want.
-
@stuartjordan said in Sodium release for helpdesk: related tickets, attachments, changed time management, etc.:
What Ticket/Helpdesk system is this?
This is the Helpdesk of the Sodium management and monitoring system. Sodium is a project code name, it'll have some cool name once it is fully in production.
-
@quixoticjeremy said in Sodium release for helpdesk: related tickets, attachments, changed time management, etc.:
@scottalanmiller said in Sodium release for helpdesk: related tickets, attachments, changed time management, etc.:
I added ticket 3 as related to ticket 1. In ticket 1, this shows up in the list like it is a sub-ticket. But it ticket 3, it does not show up at all. If 3 is a sub ticket of 1, this might make sense. But if they are just "related" it should show up the same on both sides, right?
So this begs the question of is this a functionality issue or a terminology issue. I've seen people describing what they want as both related or sub ticketing. I tend to lean towards sub ticketing and creating a tree of some kind rather than just related tickets. That's just me though. Even with the tree of some kind I would want to list parent though so that's something I do need to do
Related tickets doesn't have any obvious use. What does it mean that tickets are "related"? I think that that will just cause users to be confused and start relating tickets based on any factor, like similar issues or such. That might be interesting in some other way, but it seems like that needs a lot of planning.
Subtickets are the real thing, where a number of tickets are part of a larger "super ticket." The super ticket can't be closed until all sub tickets are closed. It's a ticket "collection" of sorts.
-
@minion-queen said in Sodium release for helpdesk: related tickets, attachments, changed time management, etc.:
@quixoticjeremy said in Sodium release for helpdesk: related tickets, attachments, changed time management, etc.:
@scottalanmiller said in Sodium release for helpdesk: related tickets, attachments, changed time management, etc.:
I added ticket 3 as related to ticket 1. In ticket 1, this shows up in the list like it is a sub-ticket. But it ticket 3, it does not show up at all. If 3 is a sub ticket of 1, this might make sense. But if they are just "related" it should show up the same on both sides, right?
So this begs the question of is this a functionality issue or a terminology issue. I've seen people describing what they want as both related or sub ticketing. I tend to lean towards sub ticketing and creating a tree of some kind rather than just related tickets. That's just me though. Even with the tree of some kind I would want to list parent though so that's something I do need to do
Is there a way to do this via tags instead? Cause honestly trying to find a ticket number that had similar issues etc.... well who's going to remember that?
Exactly, using the term "related" makes it seem like it is for "groups of similar issues" rather than the actual intention which is to have it be tickets that are solidly part of another ticket.
-
@quixoticjustin said in Sodium release for helpdesk: related tickets, attachments, changed time management, etc.:
@quixoticjeremy said in Sodium release for helpdesk: related tickets, attachments, changed time management, etc.:
@scottalanmiller said in Sodium release for helpdesk: related tickets, attachments, changed time management, etc.:
I added ticket 3 as related to ticket 1. In ticket 1, this shows up in the list like it is a sub-ticket. But it ticket 3, it does not show up at all. If 3 is a sub ticket of 1, this might make sense. But if they are just "related" it should show up the same on both sides, right?
So this begs the question of is this a functionality issue or a terminology issue. I've seen people describing what they want as both related or sub ticketing. I tend to lean towards sub ticketing and creating a tree of some kind rather than just related tickets. That's just me though. Even with the tree of some kind I would want to list parent though so that's something I do need to do
Related tickets doesn't have any obvious use. What does it mean that tickets are "related"? I think that that will just cause users to be confused and start relating tickets based on any factor, like similar issues or such. That might be interesting in some other way, but it seems like that needs a lot of planning.
Subtickets are the real thing, where a number of tickets are part of a larger "super ticket." The super ticket can't be closed until all sub tickets are closed. It's a ticket "collection" of sorts.
Thus my concept was correct, I simply mislabeled. Fine by me :).
-
@dustinb3403 said in Sodium release for helpdesk: related tickets, attachments, changed time management, etc.:
When closing tickets it would be good to either remove them from the view, or provide a top level status of "Closed".
There needs to be "Ticket Views" in the short term. Open Tickets, Closed Tickets, Resolved Tickets and other "status" views. And then another set of viewing items for "My Tickets, My Organization Tickets, My Team Tickets, All Tickets" and so forth.
-
@quixoticjustin said in Sodium release for helpdesk: related tickets, attachments, changed time management, etc.:
@dustinb3403 said in Sodium release for helpdesk: related tickets, attachments, changed time management, etc.:
When closing tickets it would be good to either remove them from the view, or provide a top level status of "Closed".
There needs to be "Ticket Views" in the short term. Open Tickets, Closed Tickets, Resolved Tickets and other "status" views. And then another set of viewing items for "My Tickets, My Organization Tickets, My Team Tickets, All Tickets" and so forth.
Which is the filtering that I already spoke on.
-
We pushed out a small update this afternoon. Nothing major.
-
@stuartjordan said in Sodium release for helpdesk: related tickets, attachments, changed time management, etc.:
@quixoticjeremy Thanks for confirming, I have signed up and I will take a look around.
Welcome to the Sodium test group!
-
any plan for iOS or android app?
