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

Compare with Current View Page History

« Previous Version 82 Next »

This section focuses on Incidents processing by the agents.

Role required: incident_manager.

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 the incident you want to work on;
  2. Find the Assignment Group field, then click the magnifier icon to select a group to assign the incident to;
  3. (Non-mandatory step) complete the same step for the Assigned User field.

The incident is assigned.

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

  1. Open the incident you want to work on;
  2. Change the desirable field(s);
  3. Click Save.

Your changes will be displayed in the Activity log, that is located in the Notes tab (scroll down the page).

The following information is displayed:

  1. Update author;
  2. Field updated;
  3. New field value;
  4. Old field value.

Activity view

Create a "parent-child" relationships between incidents


Create a such relationship 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 open the Related Records tab;
  3. Unlock Slave Incidents. For this, click a lock icon.
  4. Click a magnifier icon to select an incident that will be slaves for this one. You can choose over one incident, in this case, all of them will be slaves for it.
  5. Click the lock icon again and then click Save.

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

To create a parent 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 open the Related Records tab;
  3. Click a magnifier icon on the Master Incident field;
  4. Select incident you want to be a parent for this one and then click Save.

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

Create an Incident Announcement

Create an announcement informing related to the Incident processed.

To create an Incident announcement, please click the Create Announcement button in the Incident form.

In there, two types of announcements are available:

  • Recovery - this type of announcement informs that some service or CI recovery activities have been started;
  • Completion Recovery - this type of announcement informs that some service or CI recovery activities are over.

Create an Incident Task


If solving of incident requires the participation of various 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 open the Incident Task tab;
  3. Fill in the form:
    1. Number - filled automatically;
    2. State - leave it in the Pending state;
    3. Incident - filled automatically with the number of the parent incident;
    4. Assigned user -  choose a responsible person you wish to assign a task to;
    5. Assigned group - choose a department you want to assign a task to;
    6. Subject - describe the task here in a brief manner;

    7. Description - 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 assigned person started to work on this task. This field must be filled by the agent;
    2. Actual End Date - the date when the assigned person finished the work on this task. This field must be filled by the agent;
    3. Planned Start Date - the date when you want the assigned person to start working on this task;
    4. Planned End Date - the date you want this task to be finished (completed and closed).
  5. Click Save.

You can create as many Incident Tasks 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 open 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. Click a lock icon, then click a magnifier icon;
    2. In the new window appeared choose a necessary option;
    3. Click the lock icon again and then click Save.
  5. To create relationships for the Known Error, Master Incident, Related Incident, please complete the following steps:
    1. Click a magnifier icon;
    2. In the new window appeared choose a necessary option;
    3. Click Save.

Relationship types

TypeDescription

Solved by Change

The incident is solved / can be solved by the Change specified.

Caused by ChangeThe incident is caused by the Change specified.
Related ProblemsThe incident is related to the Problems specified.
Known ErrorThe incident is a Known Error, it has a recorded root cause and a workaround.
Related InquiryThe incident is related to the Inquiry specified.
Slave IncidentsThe incident has one or more child incidents (see above on this page).

Master Incident

The incident has a master incident (this essence is opposite to the child incidents).

Related RequestThe incident is related to the Service Catalogue Request specified.
Related ArticleThe incident is related to the Knowledge Base Article specified.


Closure information


Based on the SimpleOne state model, when the incident was resolved, it must be marked as Completed, that will denote the incident closure. Also, the agent must provide the following details:

  1. Closure Code;
  2. Closure Notes.

Closure Code

This code specifies an option of the closure. SimpleOne has the following options:

OptionDescription
Solved 1st levelThe incident was solved by the 1st level of service agents without functional escalation.

Solved 2nd level

The incident was solved by the 2nd level of service agents (1st level was not unable to solve).
Not Solved (Unable To reproduce)The agents couldn't reproduce the incident and didn't find any disfunction.
Not Solved (Dropped)This closure code is chosen when the request is not an incident at all (for example, it's a Change Request).
Not Solved (No User Reaction)This closure code is chosen when the user didn't provide additional information after he was asked about this in the Information Needed Incident.
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

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

Escalation Rules


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

  • Functional escalation is when 1st level service agents 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 may take an excessive amount of time. It's an escalation up to the management.

In SimpleOne, 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 assigned person or group 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 assigned person or group manager is being notified about this repeatedly.

Also, you can keep the line manager of the assignee informed about the incident activities by clicking the "Notify Manager" button on the form.

One of the examples of the hierarchical escalation:

If the incident solution was rejected by the caller (state Rejected by User was set) two times, then the automatic notification is sent to the assignee' manager.

Indication

Every incident has SLA indicators quantized and tied up. They can be found at the bottom of the incident page, in the Indication Tab. This tab displays the following information:

  1. Start time;
  2. Has breached;
  3. Stop time;
  4. Business Elapsed Time;
  5. Business Time Left;
  6. Breach Time;
  7. Pause Time.

SLA Indicators

Indicator

Description

Start timeThe indication start time. This field is linked with the incident Registered state.
Has breachedThis field displays whether SLA has been breached or not.
Stop timeThe indication stop time. This field is linked with the incident Completed state
Business Elapsed TimeThis field displays how much business time has passed since the incident was created.
Business Time LeftThis field displays how much business time is left until SLA will be breached,
Breach TimeThe time value of how much SLA has been breached in this incident.
DowntimeThe downtime duration.

In SimpleOne, SLA indicators can be determined based on three entities: field, operator and value.

You can create your own SLA indicators using the Condition Builder. To create it, navigate to the Service Level Management → Timepoint Indicator and click New.

For example, you can create separate SLA indicators for incidents having an impact from "Low" to "Very High" and set a separate "Breach Time" value for them, based on your SLA agreement.

Incidents Prioritization


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. 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 has an impact on the business. In SimpleOne, the urgency can be categorized as:

  1. Low;
  2. Medium;
  3. High.

Based on the priority, incidents can be categorized as:

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

Priority Management
The priority matrix
Impact / UrgencyLowMediumHighVery High
LowLowLowModerateHigh
MediumLowModerateModerateHigh
HighModerateModerateHighCritical
Very HighHighHighCriticalCritical

  • No labels