Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,300,432
Community Members
 
Community Events
165
Community Groups

Product vs Operational categories vs Services

I'm trying to get my head around the categorisation of a ticket.

The main options it would seem are services, product categories and operational categories.

How are others using these combinations? What's the difference between an operational category and a product category?

The only reference I've really been able to find is this one:

Guidance for Product categorization and Operationa... (atlassian.com)

I've read various ITSM guides on incident categorisation but that doesn't directly link to how Jira categorises issues/requests with product and operational categories.

Paul

2 answers

1 accepted

1 vote
Answer accepted

Hi @paulcreedy,

Both fields are pre-filled with sample data from Atlassian templates. They contain the following default options ...

for Product:

Screenshot 2022-06-12 at 19.11.53.pngand for operational:

Screenshot 2022-06-12 at 19.12.33.png

The main thing I derive from those preset values, is what they are intended for. While you can use product categorisation clearly to approach your tickets from the viewpoint of "what tangible item is this request about", the operational categorisation rather starts from "what do you, service desk customer, want us to do for you". 

The many templates JSM offers are in the box to make it easy for users to spin up a service desk that is operational in no time. And, while that is awesome, the reality is that you would usually have to do some tweaks to make the thing work for your situation.

Basically, you could even forget about these fields entirely. In the end, the title of your request type could cover either approach. But I would recommend to be consistent and, when you start defining the request types that your customers will actually have to use, offer them one of both ways to contact you. Which is best, will be very much defined by how you prefer to interact with your customers (in the first place) and how you triage work to your internal service teams.

Finally, one more thing. I remember 1 single situation where I actually used categorisation custom fields on top of the request types. This was a situation where we decided to offer only 2 request types to the customers:

  • "I want to report a problem" (which was the type for incidents)
  • "I want to ask a question" (which was the bucket for service requests)

In that situation, it was obviously necessary to let people choose what the problem or question was about. That more or less automagically mapped best to the tangible assets I referred to earlier. You can use the categorisation field that's in the box for that, but nothing stops you from creating your own fields that match your way of working.

This is not a binary yes-or-no kinda thing, but I hope this helps!

Thank you Walter

While there isn't a correct answer to this, as they are after all just drop down categories that could be used in whatever manner that fits, you answer does make sense based on those samples.  I'd rather stay within convention as much as possible with the original intention of those fields.

Most of the category selection will be done by the agents when the ticket is first-lined, because I know from experience that end users rarely fill those in and when they do often get them wrong.  

The main reason from my point of view of correctly categorising a ticket is so that the reporting on them helps identify where the problems are; on the lines on there's no point having a category selection for something if there is no intention of reporting a KPI in that area;  It just becomes noise and effort otherwise

To summarise then to see if these examples work and for anyone else that finds this thread useful:

Product categories appear to be geared to 'what has broken', whilst Operation categories appear to be more 'The action to be performed'.

Examples:

1. Users monitor has broken

Product: Hardware > Monitor | Operational: Hardware > Replacement

2. User requests installation of software

Product:: Software > Office 365 | Operational: Software > Installation.

3. A hyper-v server is low on disk space

Product:  Virtualisation > Hyper-V server  |Operational: VM Request > Expand the drive.

4. User has deleted a document or it is corrupt

Product:  Documentation > Loss/Corruption | Operational: Documentation > Recovery

 

From that data we could then gain insight into issues and time taken by agents into:

How reliable hardware is and where fix or replacement is the answer?

What software is being requested that should have been installed already

How often VM's are running out of disk space and the time taken to sort that out.

How often documentation is being lost of corrupted, do we have a document or user issue?

 

Thanks again for your help

Paul

1 vote
Brant Schroeder Community Leader Jun 10, 2022

@paulcreedy 

I wouldn't say that there is any particular right way to organize your request types within a service desk.  Each service desk will serve different organizational needs.  The service desk allows you to manage your service desk to meet your customer's needs best.   I often see organizations organize their request to align with their service centers.  This makes it easy for individuals to find the request that they need to submit.  I would focus more on how you can best serve your customers so they can quickly find the request that they need to submit.

Hi Brant

I appreciate each organisation is different but based on both of these being drop down lists of two tiers, and the way they are named I would have thought that Jira would have had something specific in mind for their use

The wording Product and Operational implies different usage or convention between them.

Services seem to be geared to change requests or incidents on critical organisation services since they work across projects but can't be seen by end users, as well as having approvers. Whereas product and operational seem project specific and can be seen by end users.

Operational to me implies internal category usage whilst product implies customer focused but ai may be wrong there.

I think it would be good to see some examples on how others are using them.

Paul

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
FREE
PERMISSIONS LEVEL
Site Admin
TAGS
Community showcase
Published in Jira Service Management

Improving the Create Issue Experience in Jira Service Management Cloud

Hello everyone!  We are very excited to announce some much needed changes to the issue create experience in JSM (the blue "create" button) at the top of the screen.  We have just starte...

156 views 7 5
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you