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

State and Status

The status of a request is based on the state of the request.

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.

Easily convert resolved requests to Knowledge Base articles. KB icon appears post-resolution, ensuring efficient knowledge management.

Last updated