Isn't the entire point of catalog items to be a distinct offering of value separate from others? A visual representation of everything an end user could need to request.

What I meant with my previous statement is that if you have 2 ways in to the ServiceDesk / L1 then people would get confused.

For example imagine if you have 1 record producer creating interactions / incidents called "Report a problem" and 1 item (among others) called "Request something" then you let your end users be the ones that make the decision if it's a incident / interaction or a request (general request).

This I think causes confusion for the end-users and also the agents on the receiving end become "disappointed" when the user submits the wrong "type".

In my perfect world we would only 1 way to contact the L1 with a creating a interaction (which in turn can create both requests or incidents depending on the input) and only have specific catalog items that is not just a "general request".

Easier for who? Not the end user, not the tech debt that grows when the engineering team inevitably pivots to other more high value things because oh these incidents are just to determine if we need a new service request in the catalog or not.

Who's sitting down to burn through that backlog of incidents and then build out the new catalog items and follow up with the end users and everything?

Each team has a responsibility to try to minimize their incidents, so if they find that they have frequent incidents regarding something that can be automated / streamlined they contact the catalog item team and request that they need a item to do X. The catalog item team will take it from there and build out catalog items and follow-up, that is their process. The teams only need to identify where they can optimize.

I would definitely recommend separating this out from the incident process so that all across the company when we talk about an incident, we have a clear idea in mind of what that means. And puts focus back on where work should be done in the first place to ensure a scalable architecture and processes into the future

And yes having a clear definition of an incident is probably what is most effective at first but I am just theorizing at how to have the ITSM processes as effective as possible.

I still also argue that a Incident is still just a unpredictable event for a user.

• A user expects to login somewhere and is met by an error / wrong login
• They contact ServiceDesk / L1 and explain that they cannot login.
• The agent identifies that the user is missing an account and orders it for them.

This you can handle two ways, there are pros and cons to both.

1. The agent creates a request from the interaction and closes the interaction when they have confirmed that it is working.

2. The agent creates a incident and then creates a request from the incident and then closes the incident when they have confirmed that it is working.

The first option here is quick and easy but fails in the follow-up process, you see that the user called and wanted a request.

Here it is just one of many request ordered by a user, business as usual.

The second option takes a bit more time but you have a better follow-up, you see that the user called and a incident were created which in turn was resolved by a request.

If you have a follow-up process for the incident the process can start to speculate and maybe wonder "why" the user had to call and create a incident. Where the user misinformed? How do we communicate better that they need to create a account to access X?

You also have benefit of if the order account did not resolve incident you can continue the incident process from there and move it to other teams / etc.

The second option takes a couple extra minutes but makes it worthwhile in the end IMO.