Product vs Operational categories vs Services

[paulcreedy]

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

[Walter Buggenhout · Accepted solution]

Hi @paulcreedy,

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

for Product:

and for operational:

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!

[paulcreedy]

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

[Brant Schroeder]

@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.

[paulcreedy]

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