Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Incidents Table

Incidents are used to report service problems and outages. They are interruptions to customer service. The objective is to return to the normal service as defined in an SLA as quickly as possible with minimal business impact. An example Incident for an end user might be: "I cannot access my email".

What is the distinction between Service Request and Incident? Incidents are interruptions or degradations of an existing service that need to be rectified. They are problems that need to be solved, rather than a request for new service or a change to a functioning service, such as a new employee setup or new software application request.

Incidents may result from underlying problems caused by misconfiguration or hardware failures, and an underlying problem may result in the submission of several incidents by end users. When this is the case, the underlying problem may be reported and managed in a separate Problem record.

When an incident is caused by an underlying problem, the technician working on the incident can link the incident to an existing Problem record or convert it to create a new Problem record. They may also click the Save and Create Change Request if they wish. The Change Request table will keep track of Incidents that are converted onto it.

Problems may require significant changes in order to be permanently resolved. In this case, the technician working on the Problem will link it to a new or existing Change Request. While a Problem may stay open until the Change is implemented, often a workaround is found to resolve the interruption in service for the customer.

The system is set up to make it easy to generate and relate Incidents, Problems, and Changes, and to quickly and automatically propagate workarounds from problems into all related Incidents.

Use Case

Incidents may be created by internal customers through the web portal or via email, or by a technician taking a telephone call from a customer. They may also be created by network monitoring systems configured to send problem reports to the system through one of the standard APIs. A field in the Incident form specifies the reporting source, such as email, web, or phone. A technician may also convert a Service Request to a new Incident via an action button in the SR form if a customer submitted a Service Request when they should really have submitted an Incident. See Details of Incident Rules in the Appendix for more details.

End User Record Submission

When a customer submits an Incident, the contact fields automatically populate based on the details in the User record. In the default setup, an Incident cannot be submitted on behalf of a user who has no user record in the system. This may easily be changed by modifying the linked fields from the User table to enable "non-source" values to be used.

The customer selects a category for the Incident from the drop down list "I'm having a problem with...", such as 'Email' or 'Access Problem', then describes the problem in more detail via the Summary and Description fields.

The customer is also given two fields to describe the priority of the Incident: Impact and Urgency. Impact specifies how widespread the Incident is: A user whose desktop computer is malfunctioning would choose 'Affects Single User', whereas a critical server failure might be classified as 'Affects Company'. Urgency is a subjective measure of the criticality and time sensitivity of the Incident, and ranges from Low to Critical. Both Impact and Urgency are used to automatically determine the official Priority of the Incident, a field which is hidden from the end user and only editable by staff. See Incident Rules for the current logic used to set the Priority. Priority is only set by a rule if the staff user has not already manually set it.

After providing the summary, description, category, impact, and urgency, the user clicks Finish and receives an automatic email notification when the system creates the record.

Technician Record Submission

A technician creating an Incident sees additional information relating to the status of the Incident, including assignee and status fields. Unlike end-users, staff can see an additional section on the details tab for Asset Information that shows fields relating to a specific Asset. By default, Incidents are created with the "Problem Asset Identified?" field set to No, but if a staff person determines the Asset that is the root cause of the Incident, he or she may set this field to Yes and select a Asset via a linked field set.

By default, Incidents without an Asset identified are assigned to the 1st Level Support Team. Technicians can also set the assigned team and assigned person manually via drop-down lists in the Work Status tab. If the Problem Asset has been identified, the staffer can set the field "Assign to Asset Responsible Team" to Yes and when the Incident is saved, a rule will detect the change and assign the team responsible for the Asset selected to the Incident. A technician may change the Assigned Team field later, as the rule will only set the Assigned Team at the time the Asset field changes to Yes.

New Incidents are created in a status of Open by default. During creation, a technician may change the status to Assigned to indicate they have already started working on it, or Closed if they are able to resolve the issue over the phone and wants to capture the request for reporting purposes.

Automatic Emails Sent upon Submission

If a Support Staff technician creates a record in a status of Closed an email is sent to the customer telling them how to reopen the Incident. This email is sent by a workflow action and is displayed as a checkbox that can be turned off by technician users. This option is set in the workflow options.

If the status is not Closed when saved, the rule named "Incident - All Creation Actions" will send the customer an acknowledgement email and will also send an email to either the Assigned Person, if there is one, or to the Assigned Team if not.

Processing of Records

When a technician works on an Incident, if they needs more information from the customer in order to take further action, they can set the status to Pending Customer. A workflow action will automatically send an email to the submitter requesting further information and including the content of the Additional Information field, an append-only field that is used to communicate with the submitter. The email includes a hyperlink for the customer to click to edit the Incident directly.

If the technician needs to reassign the Incident to a different team or person, they simply change the Assigned Team and/or Assigned Person field and the system will email the new assignee notifying them of the reassignment (Rule: Incident Edit Actions, Action: I: Notification Actions).

The Staff Only Notes field is an append-only field that holds technician working notes that are not visible to the customer.

When the technician has completed work on the Incident, they set the Status field to Closed and put the solution notes into the Resolution field. This triggers a workflow email to the customer that includes the content of the Resolution fields and tells the customer that the request has been completed.

Relating Incidents to Problems

If an incident has an underlying problem that needs to be addressed, the technician may quickly convert the Incident into a related Problem record. Or they may use the Linked Problem lookup to search for existing Problems that may be the cause of this incident, and if one is found, link the Incident to that Problem.

When an Incident is linked to a new or existing Problem, the Incident may be automatically updated from the Problem record when a workaround or solution to the Problem is identified.

Within the Problem record, a button may be pressed to copy the workaround for the problem into all related Incidents, set the Status of the Incident to Workaround Provided, and email the customer and assigned rep. Another button may be pressed to populate the Problem's Solution into the related Incidents, set their Status to Closed, and email the customers.

Reporting Time Spent

Technician users may easily report the time they spend on handling Incidents. There are two fields and an action button for this purpose–Time Spent, Time Description, and Add Time–on the Working Notes tab of the layout. Entering values there will automatically create a new time entry record when the Add Time button is clicked. The time entry will show the work done by the technician and the current date.

All the time entries for a request can be seen on the Time tab as well. If a technician needs to report time that was spent on a different day or by a different user, they may click the New button on the Time spent table to submit a time entry directly and change the date or "Done by" field. All time entered is totaled in the All Time Spent field, which can be used in reporting or billing.

Note that this same time entry methodology is used in the Service Request, Problem, Change Request, and Task tables.

Customer Updates

If the customer updates the Incident at any point, an email notifies the assigned person, or assigned team if no assigned person, of the update.

When the customer replies to the email or edits an Incident in a status of Pending Customer, the status changes to Updated by Customer (Rule: Incident Customer Update Actions, Action: Submitter Update Actions) and an email notifies the assigned person, or the assigned team if assigned person is empty, that the customer has replied. The customer is able to update the Additional Information field directly and any email reply from the customer is mapped to that same field.

The closing email to customers includes a hotlink back to the record if they wish to reopen it and instructs them to explain why they are not satisfied with the solution. Clicking the hotlink will automatically change the "I Would Like To Reopen My Incident" field to Yes, which in turn sets the Status of the Incident to Reopened and notifies the assigned person (Rule: Incident Customer Update Actions, Action: Submitter Update Actions).

Workflow



Ownership

Records in the Incident table are "owned" by the individual submitter. This means each record is associated with a particular employee login and no other "end user" employee will be able to edit that record. All technician users are able to edit any Incident by default.

Reporting and Statistics

Several fields are included that are used for statistical reporting. The following fields may be of interest:

  • Number of Assignees – is auto-incremented each time the assigned person changes (Rule: Incident Edit Actions, Action: Notification Actions)
  • Number of Teams Assigned – is incremented each time a different team is put in the Assigned Team field (Rule: Incident Edit Actions, Action: Notification Actions)
  • Number of Reopens – is incremented each time a closed request is reopened by a customer
  • Total Hours to Close – elapsed time between Date Created and Date Closed
  • Working Hours to Close – elapsed time between Date Created and Date Closed minus the non-working hours of the team in the Assigned Team field and the time during which the Status was Pending Customer

There are default reports measuring Total Time Spent by Type of Problem, Average time to close by Type of Problem and by person who closed, as well as averages for number of people assigned, number of teams assigned, number of reopens, and so on. With the field structures already there, it is easy to add reports to slice and dice the information the way you need it.

  • No labels