You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 117 Next »
This section focuses on Incidents processing by the agents.
Role required: incident_manager.
State Flow
*This state model is valid for End-User incidents. Infrastructure Incidents do not have Rejected by User state.
Procedure | Status | Description |
---|---|---|
Logging | Registered | The incident is recorded (via phone/email/Self-Service Portal) but not yet categorized. |
Categorization | Assigned | The incident is categorized and assigned to a relevant person or group. |
Resolution | In Progress | The person started working on the issue. When Assigned User changes to another person, the Incident state changes from the In Progress to Assigned value. |
Closure | Completed | An incident is considered to be resolved when an agent comes up with a temporary workaround or with a permanent solution for this issue. In this case, he/she must change the status to Completed so that the caller could perform the tests. If the tests are successful, the incident should be marked as Closed; otherwise, it should be marked as Rejected by User. Also, when incident is completed, the caller can evaluate agent's performance and the service level on the whole. For this, please follow these steps:
|
Closure | Closed | After the incident caller is satisfied with the incident solution, he can close the incident (mark it as Closed and (optionally) evaluate the agent performance by grading "Agent Satisfaction" and "Service Satisfaction"). If the incident was not closed after it was marked as Completed, then it can be closed automatically over an adjustable timeframe. |
Only the incident caller has the right to close the incidents; this is the best ITSM practice. But in SimpleOne, this rule does not affect infrastructure incidents. The incidents of this type can be closed only by the responsible person after performing the tests.
Waiting Statuses
Procedure | Status | Description |
---|---|---|
Investigation and diagnosis | Information Needed | If the issue description is not clear enough, then the agent has to request additional information by changing the incident status to Information Needed. Once the information is received, the status has to be changed to the previous one. |
Resolution | Postponed | The incident can be marked Postponed if the resolving incident should be postponed for a known period. If the incident moves to this status, then planned resolving date must be specified in the Resubmission field. But if the incident affects business functions, then it must have at least a temporary workaround. |
Functional escalation | External Processing | If the incident solving requires 3rd party engaging, then, after referrals, the incident status must be changed to External Processing. And after this 3rd party engaging is over, the incident state and the assigned user should be changed to the previous one. |
Resolution | Rejected by User | If the caller is not satisfied with the agent work on the incident after completing it, then he can change the status to Rejected by User to address the defects. |
Incidents Prioritization
Incident Priority can be figured out based on its 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:
- Low
- Medium
- High
- 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:
- Low
- Medium
- High
- Very High.
Based on the priority, incidents can be categorized as:
- Low
- Moderate
- High
- Critical.
The priority matrixImpact / Urgency Low Medium High Very High Low Low Low Moderate High Medium Low Moderate Moderate High High Moderate Moderate High Critical Very High High High Critical Critical
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:
- Open the incident you want to work on.
- Find the Assignment Group field, then click the magnifier icon to select a group to assign the incident to.
- (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:
- Open the incident you want to work on.
- Change the desirable field(s).
- Click Save or Save and Exit to apply changes.
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:
- Update author
- Field updated
- New field value
- Old field value.
Activity view
Create a "parent-child" relationship between incidents
Create such relationship to link two or more incidents with each other in a "parent-child" model.
To create a child ticket, please complete the following steps:
- Start creating a new incident.
- Fill in the form, then scroll down the page and open the Related Records tab.
- Click a magnifier icon next to the Slave Incidents field. The incidents list will appear.
- Select desired incidents from the list and click the Select Items button. You can choose more that one item, in this case, all of them will be slaves for the master incident.
- The Level of Dependency field is automatically populated with the Master value and remains read-only.
- Click Save or Save and Exit to apply changes.
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:
- Start creating a new incident.
- Fill in the form, then scroll down the page and open the Related Records tab.
- Click a magnifier icon on the Master Incident field.
- Select an incident you need to be a parent for this one.
- The Level of Dependency field is automatically populated with the Slave value and remains read-only.
- Click Save or Save and Exit to apply changes.
You can also use an autosuggest feature when choosing records in reference fields, such as Master Incident or Slave Incidents fields. For this, just start typing an incident number or incident subject.
If you need to make an existing incident parent for another one, then you can skip step 1.
Master and Slave Incidents
You can close all slave incidents related to the master incident with a bulk action without navigating to a form of every slave incident and manually closing it. For this, please complete the steps below:
- Make sure that the master incident is in the Completed state.
- Navigate to the Related Records tab and click the Close all Slave Incidents button.
After that, the state for all slave incidents will be changed to Completed, too. The closure notes and other service information will be transferred from the master incident.
Also, when you comment on a master incident, the comment you made is transferring into slave incidents in two ways depending on the comment type:
- The comment left in the Work Notes field of the master incident is copied into relevant fields of all slave incidents.
- The comment left in the Additional Comment field of the master incident is copied into relevant fields of all slave incidents, and in addition, a comment announcing notification is sent to the incident caller.
Create an Incident Announcement
Create an announcement to inform about the Incident being 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 incident solving 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:
- Open the incident you want to work on.
- Scroll down the page, then open the Incident Task tab.
- Fill in the fields.
- Click Save or Save and Exit to apply changes.
Field | Mandatory | Description |
---|---|---|
Number | Y | This field is populated automatically. |
Parent | Y | This field is populated automatically with the number of the parent incident. |
State | N | Available options:
|
Assigned User | Y | Choose a responsible person you wish to assign the task to. When an incident has been assigned to a responsible user, then the Assigned Group field becomes non-mandatory. The same goes for other task objects, like change requests, or service requests. |
Assigned Group | Y | Choose a responsible group you wish to assign the task to. When an incident has been assigned to a responsible group, then the Assigned User field becomes non-mandatory. The same goes for other task objects, like change requests, or service requests. |
Subject | Y | Specify the task subject. |
Description | N | Describe the task by giving more details. |
Followers list | N | In there, users list who follow the task for tracking updates is displayed. |
Schedule tab | ||
Planned Start Datetime | N | The date when you want the assigned person to start working on this task. |
Planned End Datetime | N | The date you want this task to be finished (completed and closed). |
Actual Start Datetime | N | The date when the assigned person started to work on this task. This field must be filled by the agent. |
Actual End Datetime | N | The date when the assigned person finished the work on this task. This field must be filled by the agent. |
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:
- Open the incident you want to work on.
- Scroll down the page, then open the Related Records tab.
- You can create these types of relationships:
- Solved by Changes
- Caused by Changes
- Related Problems
- Known Error
- Related Inquiry
- Slave Incidents
Master Incident
- Related Articles.
- To create these relationships, please complete the steps below:
- Click a magnifier icon next to the appropriate field.
- In the appeared window choose a necessary option and click Save.
Relationship types
Type | Description |
---|---|
Solved by Change | The incident is solved / can be solved by the Change Request specified. |
Caused by Change | The incident is caused by the Change Request specified. |
Related Problems | The incident is related to the Problems specified. |
Known Error | The incident is a Known Error, it has a recorded root cause and a workaround. |
Related Inquiry | The incident is related to the Inquiry specified. |
Slave Incidents | The 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 Article | The incident is related to the Knowledge Base Article specified. |
Closure information
Based on the SimpleOne state model, when the incident is resolved, it must be marked as Completed, that will denote the incident closure. Also, the agent must provide the following details:
- Closure Code
- Closure Notes.
Closure Code
This code specifies an option of the closure. SimpleOne has the following options:
Option | Description |
---|---|
Solved 1st level | The 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 (the 1st level of service agents was unable to solve it). |
Not Solved (Refused) | 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 during the Information Needed phase. |
Not Solved (Other) | This closure code is meant to be 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. |
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:
- 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 notified about this.
- If the things have not been changed, then incident urgency increases, the incident rises up in line.
If it didn't help, then incident urgency increases again, the incident rises up in line, the assigned person or group manager is notified about this repeatedly.
Also, you can keep the line manager of the agent 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 agent's manager.
- No labels