Incident State Model *
* This state model is valid for End-User incidents. Infrastructure Incidents do not have Rejected by User state.
| Excerpt |
|---|
The states can be divided into State Flow and and Waiting statuses. The difference is that when the incident is in the the State Flow state state (for example, In Progress), SLA indicators are are continuing to count down the time related to the incident processing. For example, it can be the time until the SLA breached (the Business Time Left indicator). But when the incident is moved to the the Waiting status status (for example, Information Needed), all SLA indicators related to the incident stop the countdown. |
SLA-based Statuses
Status | Description | Available Transitions | |
|---|---|---|---|
| Registered | The incident is recorded (via phone/email/Self-Service Portal) but not yet categorized. |
| |
| Assigned | The incident is categorized and assigned to a relevant person or group. |
| |
| In Progress | The responsible person has started working on the issue.
|
|
| |
| 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. |
|
| Closed | After the incident caller is satisfied with the incident solution, he/she could 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. |
| Info |
|---|
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 affect infrastructure incidents. The incidents of this type can be closed only by the responsible person after performing the tests. |
Waiting Statuses
Status | Description | Available Transitions |
|---|---|---|
| Information Needed | If the issue description is not clear enough, then the agent has to request additional information by changing the incident status to to Information Needed. Once Once the information is received, the status has to be changed to the previous one. |
|
| Postponed | The incident can be marked marked Postponed if the incident resolving should be postponed for a known period. If the incident changes to this status, planned resolving date must be specified in the the Resubmission field. But But if the incident affects business functions, then it must have at least a temporary workaround. |
|
| External Processing | If the incident solving requires 3rd party engaging, then, after referrals, the incident status must be changed to External Processing. And And after this 3rd party party engaging is over, the incident state and the assigned user should be changed to the previous one. |
|
| Rejected by User | If the caller is not satisfied with the agent's work on the incident after completing it, then he can change the status to to Rejected by User to address the defects. |
|
| Table of Contents | ||||
|---|---|---|---|---|
|