> For the complete documentation index, see [llms.txt](https://docs.infraon.io/infraon-help/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.infraon.io/infraon-help/infinity-user-guide/request-management.md).

# Request Management

A Service Request is a formal request raised by a user for information, support, access to IT, or something new to be provided. In Infraon, service requests are called "Request." Request Management is the process responsible for managing the life cycle of requests. Request Management aims to support the agreed quality of service by handling all pre-defined, user-initiated requests in an effective and user-friendly manner. 

Infraon's Request Management module enables users/organizations to achieve their goals through the following steps: 

* **Request Recording** - This is the first step of request management. A user identifies the need for a service and formally requests it through the request management portal. Requests can be raised through the following channels: 
  * logging a request through the portal 
  * sending an email to the service desk mail address 
  * calling the service desk helpline number 
* **Classification & Organization**- Though requests can be identified and recorded by anyone (agents/technicians/end users), it is the responsibility of the service desk agent to classify and organize them appropriately. Requests have a type and classification. 
* **Initial support**- Once identified, based on the simplicity of the service requested, the service desk technicians can offer initial support to the requester. 
* **Escalation** - If an agent feels that the request is more of a ticket and impacts a service, he can convert it into a ticket and assign it to the appropriate team. 
* **Resolution** - Resolution provides the information requested by the requester, new hardware provided to the requester, and so on. 
* **Closure**- The service desk technician adds a note and marks the request as Resolved. A request is considered closed only when the requester agrees on the resolution given. 

## **Request Transfer state** 

In addition to these, Infraon also covers request ownership, monitoring, tracking, and communication throughout each request's life cycle. 

Requests are managed through the "Request" module. They can be raised by service desk agents or end-users, referred to as requesters. Requests follow multiple state(s) and status(es) throughout their life cycle. 

**Request Logging**: State Open, Status New 

**Request Categorization:** Status Assign- Categorize Request Type, Service Classification, Priority, Followers, Tags 

**Request Diagnosis:** State In progress, Status Analysis 

**Escalation Functional:** State In progress, Status Escalated 

**Resolution:** State Resolved, Status  Waiting for closure (Provide Resolution) 

**Closure:** State Closed, Status Completed(Update closure Category, Closure Note 

<figure><img src="/files/p24v392wpKgPpoprFhsY" alt="ITSM Request Workflow"><figcaption><p>Request Workflow</p></figcaption></figure>

## State and Status  <a href="#toc174553195" id="toc174553195"></a>

The status of a request is based on the state of the request.&#x20;

| **State**   | **Status**             | **Status Scenario**                                                                                                                                                                                          |
| ----------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Open        | New                    | When a request is newly logged.                                                                                                                                                                              |
| In Progress | Analysis               | When the request is in progress, and the technician is performing an analysis of the request.                                                                                                                |
| In Progress | Escalated              | When the request is in progress and is being escalated due to missing or incomplete information.                                                                                                             |
| On-Hold     | Pending for User Input | The status can only be "Pending" when the request is kept on hold while waiting for user input.                                                                                                              |
| Resolved    | Accepted               | When the request is resolved, and the customer accepts the solution. Once the customer marks it as accepted, the request will be automatically redirected to Formal closure with the State marked as Closed. |
| Resolved    | Resolved by Event      | When the request is automatically closed by an external event.                                                                                                                                               |
| Resolved    | Waiting for Closure    | Information is to be updated when the request is resolved and is waiting for closure.                                                                                                                        |

Customized Status(es) can be configured from the "Workflow" module to suit the requirement.&#x20;

{% hint style="info" %}
Easily convert resolved requests to Knowledge Base articles. KB icon appears post-resolution, ensuring efficient knowledge management.&#x20;
{% endhint %}