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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.