# Ticket Management

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

* **Ticket Detection and Recording** - This is the first step of ticket management, which involves an end-user identifying an interruption and deciding to record it by submitting a ticket. Tickets can be submitted by
  * logging it directly on the portal
  * sending an email to the service desk mail address
  * calling the service desk helpline number
  * using the Infraon mobile app (future release)
* **Classification & Categorization**—Though tickets can be identified and recorded by anyone (agents/technicians/end users), the service desk agent must classify and categorize them appropriately. Tickets are usually given a category and sub-category.&#x20;
* **Initial support** - Once identified, based on the simplicity of the issue reported, the service desk technicians can offer initial support to the requester.
* **Investigation & Diagnosis** - Next, the service/help desk agent moves on to troubleshoot the issue reported by investigating it further and coming up with a diagnosis. It is not about finding the root cause and fixing it with tickets. Tickets are about resuming services ASAP, which means finding workarounds, temporary fixes, etc.
* **Escalation & Notification** - When a ticket requires additional or advanced support, support/help desk agents escalate to the next level of support (L2/L3) or field engineers while informing the requester and technicians of the proceedings.&#x20;
* **Resolution & Recovery**—Resolution is a workaround/temporary fix/software patch that is applied and confirms that the service is recovered/restored.
* **Ticket closure**—Though the service desk technician adds a resolution and marks recovery, a ticket is considered closed only when the requester agrees to the resolution.
* **Auto Closure for tickets**: The system configuration automatically closes the ticket after the specified days. Requests can be applied similarly, making managing and completing large requests easy.

Infraon also covers ticket ownership, monitoring, tracking, and communication throughout each ticket's life cycle.

<figure><img src="/files/N2VNJs5fe9agaxgCNrd1" alt="ITSM Ticket Lifecycle"><figcaption><p>Ticket Lifecycle</p></figcaption></figure>

### Lifecycle

Tickets are managed through tickets. Tickets can be raised by service desk agents or end-users referred to as requesters. Tickets follow multiple state(s) and status(es) through the life cycle of a ticket.

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

**Ticket Categorization:** Status Assign - Categorize Service Category, Service, Impact, Urgency, Priority, Source

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

**Escalation Functional:** State In progress, Status Escalated&#x20;

**Escalation Hierarchical:** Runs in the back end (Automatically)

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

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

<figure><img src="/files/qJdN14evXGR9KNI2bKCX" alt="ITSM Ticket Workflow"><figcaption><p>Ticket Workflow</p></figcaption></figure>

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

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

| **State**   | **Status**                | **Status Scenario**                                                                                                                                                                                                      |
| ----------- | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Open        | New                       | When a ticket is newly reported.                                                                                                                                                                                         |
| In Progress | Analysis                  | When the ticket is in progress, and the technician is performing an analysis of the ticket detail.                                                                                                                       |
| In Progress | Escalated                 | When the ticket is in progress and is being escalated due to missing or incomplete information.                                                                                                                          |
| On-Hold     | Pending                   | The status can only be ‘Pending’ when the ticket is kept on hold.                                                                                                                                                        |
| Resolved    | Accepted                  | When the ticket is resolved, and the Customer accepts the solution. Once the customer marks it as accepted, the ticket will be automatically redirected to Formal closure of the ticket with the State marked as Closed. |
| Resolved    | Rejected                  | When the customer does not accept the solution, it is marked as Rejected, automatically resulting in Reopen of the ticket.                                                                                               |
| Resolved    | Resolved by Event         | When the ticket is automatically closed by an external event.                                                                                                                                                            |
| Resolved    | Resolved by Origin ticket | When the ticket is closed by primary/parent ticket                                                                                                                                                                       |
| Resolved    | Waiting for Closure       | Information is to be updated when the ticket is resolved and is waiting for closure.                                                                                                                                     |

> Customized Status(es) can be configured from the 'Workflow' module to suit the requirement.

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

**Reporting manager's approval:** Configure the approval settings and enable the approval toggle button. The system will automatically send an approval email to the reporting manager, including an approval link. This allows for a streamlined approval process and helps ensure that requests are approved or rejected. It is easy to configure and can be done in just a few clicks.

**Auto Approval Submission:** Enable the toggle button, and the approval link will be sent to accept or reject the ticket from the email. This feature streamlines the approval process and saves time for both the requester and the approval team.

**SLA Status Indication in Tickets and SLA widgets:** Visualize the SLA profile with the metric name on the panel view page, configure the SLA profile, map one or multiple metrics, and check the status of an SLA profile. The system manifests whether the SLA is achieved, breached, or canceled. Easily monitor and manage SLAs to ensure timely resolution of issues. Includes a response time count that shows the number of SLAs and corresponding profiles and metrics and indicates the number of SLAs that have been achieved or breached. This compliance-based feature provides a quick and easy way to monitor the service level agreements. With this information, you can proactively resolve any issues impacting SLAs and improve service delivery.

**Workspace Incident Action:** This feature allows users to track assigned tickets conveniently. Discover Incident actions, a dynamic set of features accessible via mouse hover, providing quick access to recent activity, interactions, attachments, and more for streamlined ticket handling.

Complete and Resolve button for simplifying ticket resolution in a single click. Moreover, the flexibility of Incident Card Inline Edit enables hassle-free updates to assignees and ticket details.

**Auto closure:** The system configuration automatically closes the ticket after the specified days. Requests can be applied similarly simply by managing and completing large requests.

**Request summary based on ticket count:** This provides a quick overview of the ticket status: open, on hold, or closed. It also lets you identify frequent issues raised multiple times, delete them using the widgets, and address them quickly. The summary is sorted based on ticket count, making it easier to identify high-volume requesters and reducing ticket resolution time.

**Re-Open:** If the user/requester is unsatisfied with the resolution, they can request that the ticket be re-opened. This can only be done when the ticket's status is ‘Waiting for Closure.’ If the ticket is marked as ‘Closed,’  a new ticket must be raised.

#### **Demo data for ITSM module Ticket for new Org**

Knowledge Base Modules! Explore added knowledge articles to understand the functionality and purpose of KB modules.

This new ticket can be linked to the parent ticket.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.infraon.io/infraon-help/infinity-user-guide/ticket-management.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
