Incident Life Cycle

In the company with the configured incident handling system there is an incident - the printer of the employee named Mary does not work. She submits the request to the company's service desk. Let's follow the life cycle of this request - from submitting to resolving a problem and closing the request.

Mary logging into the system and submitting the request: Service Desk -> Create request.

To create a request, she needs to classify it by selecting the appropriate service, category and type of request.

1. Mary selects the Print Service.
2. She is not sure about the category and selects the Incident/Other.
3. The request type is automatically set according to the selected category - Request for Incident. The user moves to the incident description stage.
4. Next is a description of the problem. For example, she can insert an error screenshot here.
5. Mary chooses request tags:
   • Priority - High (since the incident occurred at the end of the month and she needs to print and sign important papers)
   • Platform - Windows
6. After filling in the request data, the Create button must be clicked - the request will be submitted.

The Request for Incident is pre-configured by the administrator. It is configured to assign a service desk operator for all the created requests of this type.

The operator named John gets a notification about the creation of a new incident request. He browses the request. John does not satisfy with the content of this request - the information about the printer and its locations is not specified. He decides to clarify the required information using the internal chat that is located at the bottom of the form.

Mary receives a message. She can view it in the Discussion or by opening the request form on the website. Mary responds to the message.

This information is enough for the operator to start working. John corrects the request category and gets to work while changing the request stage to In Progress.

The operator finds the necessary printer on the network, enters it through the web interface and sees that the printer has run out of paper. He informs the employee using the internal chat. John is not very happy with the fact that the employee could not see the lack of paper in the printer. It is good that the chat supports the use of smileys and he can express his emotions.

After that, the operator John moves the request to the Done stage.

Mary sees a change of the request stage from the Service Desk page.

She opens the request and sees the operator response. Mary puts the paper in the basket and the printer begins to print a lot of documents that she had time to add the queue for printing. John does not suspect that a new request for the cartridge replacement is coming soon.

Now on the request form, an employee can confirm the request execution by clicking Accept. In other case, he could reopen the request again and provide additional information by clicking Reopen.

After clicking Accept, the request will be automatically closed. Mary happily forgot to confirm the resolving of the problem - the request will be automatically closed after 24 hours in the Done stage. All this can be customized when creating a request type.