IT Service Support Issue with Issues and Sub-Issues?

IT Service Managers, IT Techs, Issues

Tracking Issues and Sub-Issues does not directly help the remediation process. In fact, if you are not really using the data, it slows the Technician down and just becomes one more point of conflict between management and those tasked with meeting the Customer’s needs. 

It is quite amazing how many conversations (More than these four, cited in the article) have surfaced over the last two months.  The conversations have been with Owners and IT Managed Service Providers worldwide regarding what they believe to be the best list of Issues and Sub-Issues. Up until recently, the conversation came up about every two years and my past response was, “until you start reporting on the data, don’t put the Technicians through the pain of filling in another field.”  

An Inside Look at MSP-Ignite Peer Group Discussions 

Eugene was the first to bring up this topic in an MSP-Ignite Service Manager Peer Group. After that Peer Group conference call, we had a strategic conversation around what accomplishment was trying to be met. It revealed that there were foundational issues related to mixing IT Service Support and Service Delivery into the same workflow.  

The next conversation was with Jason, who introduced me to the Tech Tribe and their “The Service Type List Template.” The list is extensive (255 different combinations) and my first response was that it was too much for the average Technician to deal with in the IT Service Support workflow.  

Shortly after another MSP-Ignite Peer Group call, Dan and I had a conversation. This call was different in that Dan’s company was using Issues and Sub-Issues for reporting purposes, and had already thought through the strategic thinking of “why have the list in the first place?” 

But the real turning point for me was in my conversation with Max. Max had come to the conclusion that the devices needed to be at the Sub-Issue level. His reasoning was that devices change every six months or so and we should be listing them at the Sub-Issue level where changes can be handled easier. We then discussed the limitation of having a two-level Issue and Sub-Issue, and the need for three-levels as proposed by the Tech Tribe. 

The Moment When I Started Seeing the Value… 

As we (the group of four IT Service Managers and myself) looked at the Tech Tribes list, it seemed that we needed to reorganize the columns by moving their second column (Sub-Type) to the third column (Item). It also made sense to me that the third column (Item) needed to be at the first level, or Ticket Category. This was the moment when I started seeing value in using Issues and Sub-Issues for Service Delivery.  

One of Tech Tribe’s third column Items was Install / Add. As a Ticket Category, this makes sense. Having different Ticket Categories for IT Service Delivery and another for IT Service Support works for me. Using the Ticket Type of Incident, Service Request, and Change Request would also work, but using Ticket Type limits the Employee to the same view.  

Here are some important notes while using Ticket Category: 

  • Fields of importance can be brought to the top.  
  • Fields of less importance can be pushed down, or hidden. 
  • Fields such as Issue and Sub-Issue would be major fields in the case of Service Support, if reporting on them is in place.  

 Before going on, let me just say this: I personally still have a problem with using Issues and Sub-Issues for IT Service Delivery. It seems that if something was sold or needs to be changed, there is no issue. These are good things and should be scheduled after Incidents (which is the bread and butter of the Managed Service Provider world.)  

Looking at the Tech Tribes list, I may be softening up a bit…but it will take working with a Customer and actually setting up what is proposed here before I am ready to throw in the towel and change my mind.     

So, What Should We Do With Issues & Sub-issues?  

Here is my proposed minimal list of Ticket Categories: 

  1. Incident (Tech Tribes: Failure) 
  2. Change Requests (Tech Tribes: Change) 
  3. Service Requests (Tech Tribes: Install / Add) 
  4. Net Admin  
  5. Projects** 
  6. Other 
  • Issue level represents broad groups or families of devices 
  • Sub-Issue level denotes individual devices that come and go with time 

I am still on the fence as to what to do with Tech Tribes Item “Remove.” There seems to be a big difference between removing someone from Off 365 and decommissioning a server. It will be interesting to see what the group comes up with. 

**Any time I mix the word Project and Ticket, someone will inevitably say “you should not use a Ticket for a Project.” See the Nov 2nd Article Working as Designed, IT Service Requests are a Dilemma in this series where I go on a RANT about the dual meaning of the word Project. 

Ok, enough from me on this subject – I want to know what your thoughts are on these types of “issues” ? 

Let me know in the response section below!  

p.s. for a copy of the modified list of Ticket Categories, Issues, and Sub-Issues, send me an email at 


Steve Buyze via LinkedIn 

For more about Stephen Buyze

To follow me, Stephen Buyze

For more information about MSP-Ignite Service Manager Peer Groups

For more  HDI “The Association for Technical Support Professionals.”

Please follow and like us:

1 thought on “IT Service Support Issue with Issues and Sub-Issues?”

  1. I like the idea of a restricted category list , but as a new Autotask user I am struggling with balancing ease of use for engineers with reporting functionality,

    I have been through the videos and manual but there are some things that I consider now need to be right at the top to make processing quicker.

    I am considering adding the “Security Incident” at the Category level as this is an item that needs to be quick to respond to and follows a strict incident response plan. This may include breaches and DR scenarios, although possibly I would bring DR in as a category.

    Thoughts on how this works with Autotask would be appreciated.

Leave a Reply