Typically the "User Service Request" Incident type is for a company who does not own SRM or who wants to manage all tickets from the Incident Mgt module (even if you have SRM deployed there's not a quick and easy way for a Service Desk agent to receive a call from a user, realize it's a request, and create a Work Order from the Incident Console - they have to go to the Overview Console or SRM Request interface).
In my experience, some organizations want to work ALL service requests from the Work Order form, and some want to manage them ALL from the Incident form. Very few leverage both depending on request types/ etc.
Regarding incorrect selection of a Service in SRM inadvertently creating an Incident when you want a Work Order, if your Services are categorized and named intuitively this should rarely occur as Incidents should always be named in terms of logging a problem/having an issue while request should always be categorized and named in a "I need to order/request something". If you do have a request that gets created with the wrong Service type in SRM I would recommend that your process NOT be to try to reassociate the SRM request to a different back end fulfillment record, but rather to cancel the SRM request and have them request again under the correct request. Simply reassociating another fulfillment record in the background will skew your metrics anyway.
Just my perspective, hope it helps. Nate.
Thanks Nate, that is very helpful. I suppose the scenario of the Service Desk agent having to work out if it's a request or not and then jump to the other console is more likely than selecting incorrectly catalog item.
At the moment we are receiving about one third of our requests through home grown web forms (that will be replaced by SRM) and most of the other two thirds would be coming in by phone (hopefully a higher percentage will eventually go through SRM). Our Service Desk are used to starting to complete the Incident form (eg customer details) before fully knowing what the call is about. They could change their processes, but I think they will find it frustrating.
I would still like to hear any other takes on this.
One other note, if you decide to work requests out of Incident with a type of "User Service Request" to decrease the burden on the Service Desk, you can increase the probability of requests gettting logged with the correct type flag by creating Incident Templates that mirror your SRM service requests. This will allow you to sync the categorizations, type, priority, etc with how the ticket would get created from SRM by your AOT/PDT/SRD definitions. That way when they realize it's a request they simply pick the appropriate template and all the data gets populated for them on the incident based on the template definition you setup and all they have to do is add notes and possibly assign if you've not already accounted for assignment in the template/assignment rules. Nate.
I totally agree with Nathan Aker's comments, just wanted to add a few more notes.
I have found that customers either choose to use Incidents with "User Service Request" type (populated via template) or Work Orders, they rarely interchange. When building catalogs I always recommend using Incidents only for break-fix items (often grouped into a single, requestor-console-like SRD) and using WOs and Changes for IMAC requests. Of course you can use any combination of the 3 (and more) for more complex fulfillment.
A few other things to mention:
-If your helpdesk staff is fulfilling SRs and resolving Incidents they can use the overview console to manage all tickets and tasks assigned to them/their group.
-Work Orders provide a good amount of data storage through the WO Type Fields on the Details tabs. You can name the fields using a template and store all question data in individual fields which allows for greater (but somewhat limited) reporting. All answers must be concatenated into the notes field of the incident (in general)
We have started to use SRM and we are too in the middle of deciding which fulfillment app to use when. Unfortunately BMC doesn't provide a very clear guidelines on this. We are sort of leaning towards using Change quite a bit followed by Incident and Work Order-
*Any request that modifies a CI (required update to CMDB) will use Change
*Operational request that doesn't require an RFC and typically fulfilled by Help Desk will use Incident with type User Request
*Professional service/Consulting/non-IT request to use Work Order. These request will have longer lead times and typically fulfilled by upper tier teams
I will say that I like your approach of using Change for any request that modifies CI. When we rolled out ITSM using Remedy 7.5, we attempted to use Incident for any interruption to a service and Work Order for any request - "I need, I want". The challenge we faced was that Work Order need to be customized and the form was very different than Incident, thus creating struggles for our Service Desk. As we moved to 7.6.04, a decision was made to replace Work Order with Change and a Change Type of Service Request. Although, some cases get entered incorrectly, we stick to process. If the request was entered incorrectly from SRM, we notify the Customer and recreate it. We chose not to use Incident for Service Requests because by definitition, a request for a new laptop is not Incident, as it is not an unplanned interruption to an IT Service. It's taking some time, but the Service Desk is on board.
One area I havent seen addressed that was part of the question is how do you handle requests that come into the service desk instead of going through SRM.
I have seen two solutions.
1) Create a quick entry type form that allows the service desk to capture basic information until they determine if it is a request or incident. If they flag it as a request, it pushes to work order and creates a work order. If they flag it as incident it will create an incident.
2) Have the Service Desk walk the end user through using SRM to complete the request or do a request on behalf of. Some organizations go ahead and log an incident as well to track against their ACD metrics but it is considered a first call resolved incident even though the request is still outstanding. The justification is that the call is an incident because the user was un aware or not willing to follow the normal process of using SRM. The resolution is teaching or helping them to follow the normal process.
Even though it is great that Incident has the 4 incident types, in my experience having "requests" logged in a tool called "incident" makes for a training and education nightmare. Seperating out the two into two different ticket systems really helps keep the distinction clear.