This section focuses on Incidents processing incidents as being processed by agents. You can see The following diagram shows the incident state model on the screenshot below.
| Tip |
|---|
Role required: incident_manager. |
Anchor state model state model 
| Note |
|---|
Infrastructure Incidentsincidents do not cannot have the Rejected by User state. |
The states of Incident Processing incident processing can be divided into:
- State Flow. When the Incident Processing. When an incident is in the the State Flow state, for example, such as In Progress, SLA indicators count down count down the time related to the incident processing until the SLA breachesis breached.
- WaitingIncident Processing. When the an incident is moved to the Waiting status (for example,the Waiting state, such as Information Needed), all SLA indicators related to the incident stop the countdown.
State Flow
The State Flow group includes the following procedures and states:.
| Procedure | State | Description | Available Transitions |
|---|---|---|---|
| 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 |
Someone started working on the issue. |
| |
| Closure | Completed | 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 |
assess the results. The caller receives a notification |
asking 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. |
|
| Closed |
The Agent Satisfaction and Service Satisfaction fields are present on the form to evaluate the agent performance. |
Both fields have the following values:
|
the caller can |
assess the results. |
The values of these evaluations are connected |
with the |
values of choice options.
|
If the incident |
has not been closed after it was marked |
as Completed, it |
will be closed automatically over an adjustable |
time frame as set in system properties. |
| Info |
|---|
Only the incident caller has the right to close the incidentsincident. But However, 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 Waiting group includes the following procedures and states: .
Procedure | State | Description | Available Transitions |
|---|---|---|---|
| Investigation and diagnosis | Information Needed | If 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. |
|
| 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 state, the agent should specify |
the resolving date in the |
Resumption of work field. |
But if the incident affects business functions, |
it should have at least a temporary workaround. |
| |
| Functional escalation | External Processing | If the incident solving requires |
| to involve a third party, then, after reassignment, the incident |
| state should be changed to External Processing. After the |
| third party |
| involvement is over, the agent should change the incident state and the assigned user to the previous ones. |
| |
| Resolution | Rejected by User | If the caller is not satisfied with the agent |
| 's work on the incident |
| , |
| they can change the |
| state to Rejected by User |
| to further address the defects. |
|
Incidents Prioritization
Prioritizing incidents
The incident 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:
- Low
- Medium
- High
- 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:
- Low
- Medium
- High
- Very High.
Based on the priority, incidents can be categorized as:
- Low
- Moderate
- High
- Critical.
Anchor matrix matrix Excerpt Include SAPI:Priority Management SAPI:Priority Management nopanel true
Assigning and
Updating Incidentsupdating incidents
Once the incident is registered, it should be assigned to a responsible person or group for further processing processing. To assign an incident, please complete the following steps:
- Navigate to Incident Management → All Incidents and open the incident you want to work on.
- Find the Assignment User field, click the magnifier icon
to select a user to assign the incident to. - (Optional) Complete the same step for the Assigned Group field.
- .
To perform make any updates in to the incident, please complete the following steps:
- Open the incident you want to work on.
- Change the desirable field(s)fields.
- Click Save or Save and Exit to apply the changes.
Your changes will be displayed in the Activity Feed, in history.
The following information is displayed:
- Who initiated the update
- Updated field
- Update initiator
- Field updated
- New field value
- Previous field value.
Activity view
Escalation rules
There are two possible types of escalations:
Functional. When the 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 An issue can be escalated up to the management.
Closure information
Based on the SimpleOne Incident Processing, when the state model, when an incident is resolved, it should be marked as Completed. It will denote , which denotes the incident closure. Also, the agent should provide the following details:
- Closure Code
- Closure Notes.
Closure Notes
In the Closure Notes field, you need to put down add information on works the work performed and other information related to this incident.
Closure Code
This code specifies an option for the closure. SimpleOne has the following options:
Option | Description |
|---|---|
Solved 1st level | Service agents of the 1st level |
solved the incident without functional escalation. | |
Solved 2nd level | Service agents of the 2nd level |
solved the incident (service agents of the 1st level |
were unable to solve it). | |
Not Solved (Refused) | Agents could not reproduce the incident and did not find any disfunction. |
Not Solved (Dropped) | This closure code is chosen when the request is not an incident |
, but, for example, |
a |
Not Solved (No User Reaction) | This closure code is chosen when the user did not provide additional information |
during the Information Needed 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 has a temporary workaround related to |
a known error. |
| Table of Contents | ||||
|---|---|---|---|---|
|
...