Incident/Service Request Workflow

The following figure describes the high-level Incident/Request workflow in the OOTB system.

Incident Workflow

Note: CSM uses several features to manage the Incident/Request workflow (example: The Incident Form helps create and track Incidents, One-Step Actions help move an Incident through its workflow, Automation Processes notify stakeholders via e-mails, Dashboards notifies stakeholders and track metrics, Service Catalog Templates (SCT) and Work Units (WU) allow automation of tasks, etc.).

Contributors

An Incident/Request typically involves the following contributors. Depending on your workflow and the size of your company, many of these contributors might be combined into one person:

  • Requestor: Person who initiates the Incident/Request. This is typically a Customer.
  • Creator: User who first logs the Incident/Request. This is a technician; the level varies depending on tiered support.
  • Owner: User who manages (investigates/resolves/fulfills) the Incident/Request. This is typically a technician; the level varies depending on tiered support.
  • Task owner: User to whom Tasks are assigned in order to help resolve/fulfill an Incident/Request (example: Work Unit owner, Approval owner).

Phases

The Incident/Request workflow is broken down into the following phases:

  1. Detect: Incident is detected (Portal, call, e-mail, automated). This phase is not tracked in CSM.
  2. Record: Creator logs a new Incident. Then, creator records the initial Who (Requestor), What (Description), and How (Call Source) details.
  3. Classify: Creator classifies the Incident (Service/Category/Subcategory, Priority, Major Incident, and CI).
  4. Investigate (Incident) or Fulfill (Request): Ownership is assigned. Owner investigates or diagnoses the Incident or fulfills the Request. (Owner creates/assigns Tasks to one or more Task owners, if needed.) When a resolution is diagnosed/fulfilled, owner resolves the Incident/Request (records resolution details and code).
  5. Resolve: Owner submits resolution to the Knowledge Base (as Knowledge Article), if necessary. Owner can also close the record (to finalize the process) or reopen the record (to make changes).
  6. Closed: Closed Incident/Request can be searched and viewed, but not edited.

Statuses

An Incident/Request progressing through the workflow encounters the following statuses:

Note: Incident/Request phases do not align with Incident/Request statuses.
  1. New: Incident/Request is being created, recorded (initial details), classified, and assigned to an owner.
  2. Assigned: Incident/Request has been assigned to an owner.
  3. In Progress: Incident/Request is being investigated/fulfilled and resolved by an owner.
  4. Pending: Incident/Request is temporarily paused (Stop The Clock).
  5. Resolved: Incident/Request has been resolved and is waiting to be closed.
  6. Closed: Incident/Request is closed.
  7. Reopened: Incident/Request is reopened because the issue was not fixed or reoccurred.
© Copyright 2018 Cherwell Software, LLC. All rights reserved.