JSM manual for ITSM template? Which fields/statuses to use for what?

Erik Vanderstraeten

Hi all,

I don't seem to be able to find a manual from Atlassian about "How to use the ITSM template?".

What I'm looking for is like a 'best practices guide' which explains how Atlassian sees the usage of the fields and workflows in their ITSM template.  There are of course things that speak for themselves, but there should be some document somewhere that shows Atlassians vision/idea on usage of the ITSM template.
For example: for an 'incident' request, which fields should contain which data and when to transition to which other state?

For example:

• Custom field "affected hardware" - is it the intention that we link this to e.g. Insight?
• A service request starts in "waiting for support".  I assume you put it 'in progress' as soon as enough information has been gathered to start working on it.
  • What is the difference between the "waiting for customer" and "pending" with pending reason "more info required" then?
• By default the customer seems to be able to escalate a request (status 'escalated').
  • Should we make a difference between a customer that wants more attention for his case and a 1st line support agent that needs help from a 2nd line agent?
• Understanding the differences in the different workflows (incidents, service request, changes, problems...)
  • why doesn't the incident workflow have the "waiting for support" <> "waiting for customer" states?
• What to use the 'product categorization' and 'operational categorization' for?
• ...

Michael Andolfatto_a62ntx

Hi @Erik Vanderstraeten ,

You might be interested in their ITSM Guide. I don't believe it has answers to specific questions such as "what is the use case for field X", but rather it speaks to why practices are shaped a certain way and what should be gathered from stakeholders to create a working process.

For your example questions:

>Custom field "affected hardware" - is it the intention that we link this to e.g. Insight?

Flexible depending on what you need. I don't actually have this field in my JSM/Insight instance so I'm not positive it's OOTB, but you can create custom Insight fields to display assets/objects for what is important to your business/services

 

>A service request starts in "waiting for support".  I assume you put it 'in progress' as soon as enough information has been gathered to start working on it.

Typically yes, there may be some OOTB SLAs tied to your issue that do not count down when an issue is out of your control. This is why the back and forth between Customer <> Agent statuses are helpful, and when enough information is gathered, the SLA can accurately reflect how long the ticket has really been "worked on".

 

>What is the difference between the "waiting for customer" and "pending" with pending reason "more info required" then?

I typically see WfC as gathering more information related to the request, while Pending reflects that the issue is not being actively worked on ( blocked by third-party, on hold for business reasons, etc.) Again- flexible based on your business requirements.

 

>By default the customer seems to be able to escalate a request (status 'escalated'). Should we make a difference between a customer that wants more attention for his case and a 1st line support agent that needs help from a 2nd line agent?

The Escalated status by itself usually does not do much OOTB. You can leave it as is to allow customers the option to request "better" service, and have it display in different queues/notify teams from the status change. If simply wanting more support from a 2nd line agent, perhaps consider reassigning the issue, tagging users, notifying the team/group interally.

 

>Understanding the differences in the different workflows (incidents, service request, changes, problems...) why doesn't the incident workflow have the "waiting for support" <> "waiting for customer" states?

The core ITIL practices are described in the guide I linked above, Atlassian also has resources online for best practices for each.

 

>What to use the 'product categorization' and 'operational categorization' for?

Product: Define the type of service/object resolutions for this issue apply to

Organizational: Specification for what this issue/request relates to