General Service Task and Incident Task

[Diane22]

where we are today:  we have request items tasks, we have change tasks, and we have general service request tasks

                                     the general service request (and task) cover items which are not RITM tasks on the portal and

                                     can be requested and fulfilled by an IT team.

what we are looking to implement:  incident tasks

The challenge

1.  General Service request tasks (not linked to a RITM), and Incidents records are not logged accurately by our customers.  For them, usually anything they don't have is considered as broken, and broken items of a low priority are considered as requests.  This causes bad data when evaluating service quality -vs- requests.  The receiving "analyst" should do a QA on all records to ensure accuracy prior to closing, but ... that's challenging with a high workload and tight timelines.  It's very inconsistent.

2.  we don't feel the burden should be on the customer to decide if something should be an incident or a request

What we are thinking:

1.  remove the burden from the customer (they're not very accurate, and shouldn't need to be)

2.  implement tasks on incidents (which we don't currently have)

      a.  Category:  incident / or request

      b.  would be selected (become mandatory) once the record has an "assigned to" IT analyst to evaluate

       c.  Sub-Category:  would then be things like:  access, configuration, report, etc ...  which end up being very similar between the request and the incident:  one they need, the other is broken

       d.  the incident task would auto-trigger on creating new and carry all needed information (description, CI, etc) thus eliminating the need to "travel" between layers for information

3.  no longer have the need for the analyst to convert one record type to the other

4.  All reporting could take place at the task level for all practices (would also be able to identify records which require more than one task / team to either resolve or provision.

anyone else used this approach?  any suggestions / feedback / alternatives would be appreciated.

[Kristin J · Accepted solution]

Hi Diane,

It's been a while since you posted this, so I'm not sure if you ended up going ahead with this or not. We have a somewhat similar situation where I work (trying to take the "what am I supposed to fill out/submit" burden off of our users, and we've opted to implement Universal Request. 

We're at the beginning of that journey so I don't have a lot of answers, but in general we think it's going to allow us to intake those general tickets from the user, and then create the "primary ticket" required based on the type of issue.

For example, a user can submit the general ticket (UR) of "My printer isn't working", but the receiving analyst is the one that determines whether that needs and INC, a RITM, etc.  

From the user perpective, they just see the face of the UR, and don't know what's in the background. But for your analysts and reporting, you can correctly see break/fix vs. request.