Request Management and Incident Management are different!

Examples:

Classroom Service Request: If a customer needs assistance connecting their personal computer to a projector in a classroom, this is a request. The projector is working correctly but the customer simply needs advice on how to connect the projector and is requesting a low risk change to the configuration of the room.

Wireless Service Request: If a customer would like to connect a portable device to the utexas wireless network for the first time but needs assistance in doing so, this is a service request. The customer is seeking advice on how to connect to the wireless network and may need someone to change their connection settings.

Why are Incidents and Requests Logged Separately?

Separating Incident and Request allows service owners and support groups to run more accurate and useful reports and metrics. In future phases of the UT ServiceNow project, Problem and Event Management will be available. These tools utilize Incident and CMDB (Configuration Management Database) records to alert service owners to potential issues, help them investigate and identify the root cause of an incident or group of incidents, and encourage appropriate knowledge and documentation. Logging Requests in the Incident form will skew these reports and triggers. By separating Incidents and Requests now, we're setting the foundation for more advanced processes in the future.

Request Process Flow

Note: not all requests require an approval. Many flow directly from submission to fulfillment.

Structure of a Service Request & Best Practices for Request Fulfillment

Requests contain one or more Request Items (RITMs). Each request form the customer adds to their shopping cart generates a RITM. Fulfillers do not work from Requests. Requests will close automatically when all tasks associated with all RITMS on the Request are completed.

Request Items (RITMs) contain the actual form the customer submitted and links to one or more tasks required for fulfillment. RITMs can be assigned to a fulfillment group, not an individual. Fulfillers will rarely need to interact with a RITM, but do have the ability to add comments and work notes if applicable. Status changes should be updated at the task level, not the RITM. RITMS should never be manually moved to a different Request. RITMS cannot be manually closed - they will automatically close when all associated Tasks are completed.

Tasks are tied to RITMs. Tasks can be assigned to an individual for completion. In most cases, fulfillers will interact directly with the Task. All status updates should be made on the Task, not the RITM. Tasks should never be manually moved to a different RITM. Once each task on a RITM is completed and marked as closed, the RITM will automatically be closed. Once all RITMs on a request are closed, the Request will automatically close.