Managing IT ticketing system inputs

[ianfh10]

I'm an IT analyst working in healthcare, with my role based around an EPR system (electronic patient record). Part of my role involves working in a helpdesk ticketing system, where tickets are submitted by end users. These are either incidents (something is broken in the system and needs fixing - usually more urgent) or requests (the system is working but we'd like to customise or change something - usually less urgent).

I already have my system set up in the office suite of apps, with To Do as my main driver for next actions, and OneNote as action/project support. I have other inputs, mostly Teams chats and emails which I can manage quite easily within office.

Because the helpdesk system is standalone, I'm struggling to incorporate it into my system. I try to treat it as an inbox, with the tickets as inputs, but the problem is I can't zero the inbox because the tickets stay put until they're resolved. Plus, I can't really clarify and organise them as I'd like - some tickets represent projects with hours or even days of work, while some are simply quick fixes I could class as standalone next actions. If they're larger projects, there isn't really anywhere to document a next action other than by attaching a note to the ticket, which is not a good action reminder for me because out of sight, out of mind.

I've attempted to duplicate them in my own system in To Do, so I can at least see them alongside my whole inventory, manually adding the ticket numbers to the actions and projects they relate to, but this is too much overhead for me.

Has anyone worked with a similar system or CRM? How did you manage an inbox like this that's causing friction?

 

[cfoley]

Software support with a ticketing system was part of my responsibilities in a previous job.

In that role, each developer did about 1 in 5 weeks on support, and support work took priority over other work. This meant that most of it was "work as it showed up" but some things ended up being longer term. The ticketing system was shared within the team and I was the only one who practiced GTD.

All these factors lead me to decide that the ticketing system could not be part of my GTD system, not even an inbox. Instead, it was part of my work environment. In terms of my GTD system, the ticketing system was just like the phone. If the phone rang or a ticket came in, then I could deal with the content right away or I could capture it into my inbox.

 

[michaelp6of7]

Hi Ian,

I am in a very similar environment (only 100 users) and have similar problems. I have not been able to incorporate our CMS into my Inbox or as a Project. I feel that @cfoley has the best advice since technical support tends to be reactive in nature. The advantage of practicing GTD is that you're "ready for anything" since your personal and work areas are well defined and tracked. That's better than most support people I know. This makes you better than them because you can focus, you don't forget things, and you have a system.

I'm an IT analyst working in healthcare, with my role based around an EPR system (electronic patient record). Part of my role involves working in a helpdesk ticketing system, where tickets are submitted by end users. These are either incidents (something is broken in the system and needs fixing - usually more urgent) or requests (the system is working but we'd like to customise or change something - usually less urgent).

I already have my system set up in the office suite of apps, with To Do as my main driver for next actions, and OneNote as action/project support. I have other inputs, mostly Teams chats and emails which I can manage quite easily within office.

Because the helpdesk system is standalone, I'm struggling to incorporate it into my system. I try to treat it as an inbox, with the tickets as inputs, but the problem is I can't zero the inbox because the tickets stay put until they're resolved. Plus, I can't really clarify and organise them as I'd like - some tickets represent projects with hours or even days of work, while some are simply quick fixes I could class as standalone next actions. If they're larger projects, there isn't really anywhere to document a next action other than by attaching a note to the ticket, which is not a good action reminder for me because out of sight, out of mind.

I've attempted to duplicate them in my own system in To Do, so I can at least see them alongside my whole inventory, manually adding the ticket numbers to the actions and projects they relate to, but this is too much overhead for me.

Has anyone worked with a similar system or CRM? How did you manage an inbox like this that's causing friction?

 

[Marjolein]

I am the corporate trainer of an large energy company, where the project coordinators and engineers work with ticketing systems from several systems plus large projects that are handled in respective other software systems.

After trial and error, they found out that organising their GTD-contexts around the names of the systems, was already helpful. And then defining which system needed three visits a day and whch one needed to be checked only once a week. This gave them already more overview and a feeling of grip.
And helped in spreading the attention according to priority and getting rid of the habit 'to handle who screams the loudest or the most often'. With these categories in place, it became more easy for them to control the amount of time that a certain system (and the Tickets in there) was worth.

So the mere fact of helicoptering helped to get in the reflect mode and decide whose Ticket needs to be handled first.

If there is really no need to prioritise or organise at all, just solving the one Ticket after the other, without time limit or change of order, then i do not see added value from the GTD® either.

 

[mickdodge]

My organization uses Freshdesk for our IT ticketing system. I see it as a separate inbox that I process like I would my email or a physical inbox. I do a quick daily review of the tickets and I process single next actions (e.g., user password reset) based on priority. Anything that's multi-action project level (e.g., a request to add an access point somewhere new), I use the notes option to add the next step (e.g., investigate available network drops in that area) and I follow up on that step when time and priority allows. When I return, I add the results and the next step I need to take to the notes.

I think using the notes area within the ticket is a better option than moving it to a separate system. If I need help or anything happens to me (e.g., out sick long-term, hit by beer truck), my co-workers/supervisor can view the ticket and know exactly what I've done, the results of what I've done, and know what they need to do next without duplicating work.

I review all my tickets (and associated notes) during my Weekly Review so nothing is slipping through the cracks. While it may not be an option for you, during my Weekly Review, I tend to find tickets that I could delegate to others better suited to help.

IT ticketing systems are like the postal mail...

"The mail never stops. It just keeps coming and coming..." - Newman (Seinfeld)

So don't worry about zero inbox. It'll never happen, and if it did, they wouldn't need you to work there anymore.