Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This section focuses on Incidents processing by the agents.

Create Child Incident

Create a child incident links two or more incidents between each other in a "parent-child" model. To create a child ticket, please complete the following steps:

  1. Start creating a new incident in a way as it was described here;
  2. Fill in the form, then scroll down the page and press the Related Records tab;
  3. Unlock Slave Incidents. For this, press a lock icon.
  4. Press a magnifier icon to select an incident that will be a parent for this one. You can choose over one incident, in this case, all of them will be a parent for it.
  5. Press the lock icon again and then press Save.

If you need to make an existing incident child for another one, then you can skip step 1.

Create an Incident Task

If solving of incident requires the participation of different departments, then you can create Incident Task for each of them. They will be related to the parent incident, but not like in the "master-slave" model. The better example is the "parent-child" model. 

To create an incident task, please complete the following steps:

  1. Open the incident you want to work on;
  2. Scroll down the page, then press the Incident Task tab;
  3. Fill in the form:
    1. the Number field - will be filled automatically;
    2. the State field - when just created, leave it in the Pending state;
    3. the Incident field - will be filled automatically with the number of the parent incident;
    4. the Assigned user field -  choose a technician you wish to assign a task to;
    5. the Assigned group field - choose a department you want to assign a task to;
    6. the Subject field - describe the task here in a brief manner;
    7.  the Description field - please put there the detailed task.
  4. After you have entered task details, you can move to the Schedule tab. Here you can specify start and end dates for working.
    1. Actual Start Date - the date when the technician started to work on this task. This field must be filled by the technician;
    2. Actual End Date - the date when the technician finished the work on this task. This field must be filled by the technician;
    3. Planned Start Date - the date when you want the technician to start working on this task;
    4. Planned End Date - the date you want this task to be finished (completed and closed).
  5. Press Save.
Info

You can create as many Incident Task as you need. 

Create Relationships

You can create relationships between incidents and other types of tasks. For this, please complete the following steps:

  1. Open the incident you want to work on;
  2. Scroll down the page, then press the Related Records tab;
  3. You can create these types of relationships:
    1. Solved by Change;
    2. Caused by Change;
    3. Related Problems;
    4. Known Error;
    5. Related Inquiry;
    6. Slave Incidents;
    7. Master Incident;
    8. Related Request;
    9. Related Article.
  4. To create relationships for the Solved by Change, Caused by Change, Related Problems, Related Inquiry, Slave Incidents, Related Article, please complete the following steps:
    1. Press a lock icon, then press a magnifier icon;
    2. In the new window that was appeared choose a necessary option;
    3. Press the lock icon again and then press Save.
  5. To create relationships for the Known Error, Master Incident, Related Incident, please complete the following steps:
    1. Press a magnifier icon;
    2. In the new window that was appeared choose a necessary option;
    3. Press Save.

Let us have a closer look at these relationships.

typedescription

Solved by Change

This relationship means that the incident is solved / can be solved by the Change specified.

Caused by ChangeThis relationship means that the incident is caused by the Change specified.Related ProblemsThis relationship means that the incident is related to the Problems specified.Known ErrorThis relationship means that the incident is a Known Error, it has a recorded root cause and a workaround.Related InquiryThis relationship means that the incident is related to the Inquiry specified.Slave IncidentsThis relationship means that the incident has one or more child incidents (see above on this page).Master IncidentThis relationship means that the incident has a master incident (this essence is opposite to the child incidents).Related RequestThis relationship means that the incident is related to the Service Catalog Request specified.Related ArticleThis relationship means that the incident is related to the Knowledge Base Article specified.

agents. You can see the incident state model on the diagram below.

Tip

Role required: incident_manager.

Anchor
state model
state model
Image Added

Note

Infrastructure Incidents do not have the Rejected by User state.

The states of Incident Processing can be divided into: 

  • State Flow. When the incident is in the State Flow state, for example, In ProgressSLA indicators count down the time related to the incident processing until the SLA breaches.
  • WaitingWhen the incident is moved to the Waiting status (for example, Information Needed), all SLA indicators related to the incident stop the countdown.

State flow


State Flow includes the following procedures and states:

Procedure

State

Description

Available Transitions
LoggingRegisteredThe incident is recorded (via phone/email/Self-Service Portal) but not yet categorized.
  • Assigned
  • In Progress
CategorizationAssignedThe incident is categorized and assigned to a relevant person or group.
  • In Progress
  • Information Needed
  • Completed
ResolutionIn Progress

A person started working on the issue.

  • Assigned
  • Postponed
  • Information Needed
  • External Processing
  • Completed
ClosureCompleted

An incident is resolved when the agent provides temporary workarounds or permanent solutions. The agent changes the state to Completed so that the caller could decide on the results. 

The caller receives a notification. They are asked to evaluate the agent's job and the service level. 

If the user is satisfied with the solution, the incident is marked as Closed; otherwise, it is Rejected by User.

  • Assigned
  • In Progress
  • Rejected by User
  • Closed
Closed

There are Agent Satisfaction and Service Satisfaction fields on the form to evaluate the agent performance. Each field has three following values: 

  • Below Expectations
  • Meets Expectations
  • Above Expectations.

Image Added

On the Self-Service Portal, the caller can evaluate results. Values of these evaluations are connected to the values of choice options.

  • Below Expectations = Disappointed
  • Meets Expectations = Satisfied
  • Above Expectations = Very Pleased. 

Image Added

If an incident is not closed after it was marked as Completed, it can be closed automatically over an adjustable timeframe that is set in system properties.



Info

Only the incident caller has the right to close the incidents. But in SimpleOne, this rule does not affect infrastructure incidents. The incidents of this type can be closed only by the responsible person after examination.

Waiting


Waiting includes the following procedures and states: 

Procedure

State

Description

Available Transitions

Investigation and diagnosisInformation NeededIf the issue description is not clear enough, the agent can request additional information by changing the incident state to Information Needed. Once the information is received, the agent should change the state to the previous one.
  • Assigned

  • In Progress
  • Postponed
  • External Processing
ResolutionPostponed

The incident can be marked Postponed if the resolving incident should be postponed for a known period. If the incident moves to this state, the agent should specify resolving date in the Resubmission field. But if the incident affects business functions, then it should have at least a temporary workaround.

  • In Progress
  • Information Needed
  • External Processing
Functional escalationExternal ProcessingIf the incident solving requires 3rd party engaging, then, after reassignment, the incident state should be changed to External Processing. After the 3rd party engaging is over, the agent should change the incident state and the assigned user to the previous ones.
  • In Progress
  • Postponed
  • Information Needed
  • Completed
ResolutionRejected by UserIf the caller is not satisfied with the agent working on the incident after completing it, they can change the state to Rejected by User to address the defects.
  • Assigned
  • In Progress
  • Completed

Incidents prioritization


Incident priority can be figured out based on the incident impact and urgency using a priority matrix.

The impact of an incident indicates the damage that may be caused to the business user. In SimpleOne, the impact can be categorized as:

  1. Low
  2. Medium
  3. High
  4. Very High.

The urgency of an incident indicates the measure of time until an incident impacts on the business. In SimpleOne, the urgency can be categorized as:

  1. Low
  2. Medium
  3. High
  4. Very High.

Based on the priority, incidents can be categorized as:

  1. Low
  2. Moderate
  3. High
  4. Critical.

Anchor
matrix
matrix
Excerpt Include
Priority Management
Priority Management
nopaneltrue


Assigning and updating incidents


Once the incident is registered, it should be assigned to a responsible person for further processing

Escalation Rules

There are two possible types of escalations: functional and hierarchical.

  • Functional escalation is when 1st level technicians are unable to solve an incident due to any reasons (lack of authority or competence), they escalate it to the 2nd level to address.
  • Hierarchical escalation is typically required when an incident is of a serious nature or a set of incidents that may take an excessive amount of time. It's an escalation up to the management.

In the SIMPLE system, automatic incident escalation is implemented. How it works:

  1. If the incident have not been processed for a certain period, and there is a risk of the SLA breach, then technicians' manager is being notified about this;
  2. If the things has not been changed, then incident urgency increases, the incident rises up in line;
  3. If it didn't help, then incident urgency increases again, the incident rises up in line, the technicians' manager is being notified about this repeatedly.

Assigning and Updating Incidents

Once the incident is registered, it has to be assigned to the responsible person to be processed. To assign an incident, please complete the following steps:

  1. Open Navigate to Incident Management All Incidents and open the incident you want to work on;
  2. Find the Assignment Group field, then press the magnifier icon to select a group to assign the incident to;
  3. .
  4. Add a user to the Assignment User filed by clicking the magnifier iconImage Added.
  5. (Optional) Complete (Non-mandatory step) complete the same step for the Assigned User fieldGroup field.

The incident is assigned.

Info


If you want to inform the line manager of the assignee about the incident activities, turn on the "Attention Required" checkbox

There is also a quick way to assign an incident to a current user. To do so, click the Start work button in the right top corner to become the Assigned User. The state of the incident changes to In Progress automatically. The assigned group field remains unchanged (either with a group specified or empty). This button is available for all users who are not assigned to the incident and who have the itsm_agent role, or belong to the assigned group.

To perform any updates in the incident, please complete the following steps:

  1. Open the incident you want need to work on;.
  2. Change the desirable field(s);necessary fields.
  3. Click Save or Save and Exit to apply changesPress Save.

Your changes will be displayed in the Activity log.

Priority Management

The priority of the Incident can be figured out based on its impact and urgency using a priority matrix.

The impact of an incident indicates the level of damage that will be caused to the business user.

The urgency of an incident indicates the time within which the incident should be resolved.

Based on the priority, incidents can be categorized as:

  1. Major;
  2. High;
  3. Medium;
  4. Low;
  5. Minor.

The priority matrix

Image Removed

Feed, in history.

The following information is displayed:

  1. Update initiator
  2. Field updated
  3. New field value
  4. Previous field value.

Activity view 

Image Added

Escalation rules


There are two possible types of escalations: 

  • Functional. When 1st level service agents cannot solve an incident for some reason (lack of authority or competence), they escalate it to the 2nd level service agents.

  • Hierarchical. This escalation is typically required when an incident is of a serious nature, or a set of incidents may take a lot of time. It is an escalation up to the management.

Closure information


Based on the SIMPLE SimpleOne state model, after  when the incident was resolved (by marking an incident as Completed)is resolved, it must should be closed. Before closing an incidentmarked as Completed. It will denote the incident closure. Also, the agent must should provide the following details:

  • Closure Code
;
  • Closure Notes.

Let us have a closer look at every item.

Closure notes

In the Closure Notes field, you need to put down information on works performed and other information related to this incident. 

Closure code

Closure Code

This code specifies an option of for the closure. The SIMPLE system SimpleOne has the following options:

Option

Description

Solved

1st

1st level

The incident was solved by the 1st level of technicians

1st level of service agents solved the incident without functional escalation.

Solved

2nd

2nd level

The incident was solved by the 2nd level of technicians (1st level was not

2nd level of service agents solved the incident (the 1st level of service agents was unable to solve it).

Not Solved (

Unable To reproduce

Refused)

The technicians couldn't

Agents could not reproduce the incident and

didn't

did not find any disfunction.

Not Solved (Dropped)

This closure code is chosen when the request is not an incident at all

(

, for example, it

's

is aChange

)

Request.

Not Solved (No User Reaction)

This closure code is chosen when the user

didn't

did not provide additional information after

he was

they were asked about this

in

during the Information Needed

Incident

 phase.

Not Solved (Other)

This closure code is for all other reasons.

Not Solved (Workaround)

This closure code means that the incident has no permanent solution, but a temporary workaround related to the Known Error.

Not Solved (Other)This closure code is meant to be for all other reasons.

Closure Notes

Processing infrastructure incidents


Since infrastructure incidents are created without the involvement of a business user, their state model is different from other incidents. Infrastructure incidents do not have the Information Needed and Rejected by User states. When such incidents are closed, it is not required to fill in the Agent Satisfaction and Service Satisfaction fields.In this field you need to put down information on works performed, and maybe other information related to this incident. 

Table of Contents
absoluteUrltrue
classfixedPosition

...