Incident State Model *
* This state model is valid for End-User incidents. Infrastructure Incidents do not have Rejected by User state.
The states can be divided into State Flow and Waiting statuses. The difference is that when the incident is in the State Flow state (for example, In Progress), SLA indicators 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 Waiting 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. When Assigned User changes to another person, the incident state changes from the In Progress to Registered value. |
|
| 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. |
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
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 Information Needed. Once the information is received, the status has to be changed to the previous one. |
|
| Postponed | The incident can be 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 Resubmission field. 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 after this 3rd 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 Rejected by User to address the defects. |
|
