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

# What do request statuses mean?

Understand the four Siit ticket statuses New, In Progress, Waiting and Resolved, and how they change automatically, manually or through workflows and affect SLAs

Ticket statuses are at the heart of effective request management in Siit. They help you and your team track progress, prioritize work, and ensure timely responses to internal requests. Whether you’re responding directly, setting up automation workflows, or tracking service levels (SLAs), a clear understanding of ticket statuses is essential.

### The 4 ticket statuses

Siit comes with four predefined ticket statuses that reflect the lifecycle of a request:

<figure><img src="https://2274035325-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlWFhpq2ia6gdHet0opKx%2Fuploads%2Fgit-blob-ef94990823faed3e3af8342a38016cd1eb97af7a%2FCleanShot-2025-06-10-at-18-18-24-2x-png.png?alt=media" alt="Statuses in Siit"><figcaption></figcaption></figure>

🔵 **New:** a request that has just been created and hasn’t been responded to yet.

🟡 **In Progress:** a request that has received a first response and is actively being handled.

🔴 **Waiting:** a request that is temporarily on hold—waiting for input, action, or context.

🟢 **Resolved:** a request that has been marked as completed and closed.

### How Ticket Statuses Work in Practice

Understanding how each status behaves—manually or automatically—is key to managing your workload effectively.

### New → In Progress (automatically)

When a request is created—whether via Slack, email, or the portal—it is **automatically assigned the status “New.”**

As soon as an **admin replies to the request for the first time**, Siit will automatically update the ticket status to **“In Progress.”**

This transition requires no manual action and helps identify tickets that have been acknowledged versus those that still need attention.

### Using “Waiting” (manually or via workflow)

The **“Waiting”** status can be:

* **Manually set** by an admin when a request is on hold (e.g., waiting for more details from the requester).
* **Automatically triggered** via a workflow using the request action Set request status.

This status is especially useful when combined with the **SLA Feature**:

👉 When a ticket is in **“Waiting”** status, the SLA timer can be paused—so your internal metrics reflect only the actual handling time, not the waiting periods.

### Marking as “Resolved”

A ticket is considered **“Resolved”** when it’s been closed. This can happen in three ways:

1. **Manually** by the admin in the Siit interface.
2. **By the employee**—directly from Slack or the web interface.
3. **Automatically via workflow**, using the request action Mark as resolved.

Once resolved, the ticket is considered complete, but it remains visible for reporting or auditing purposes.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

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

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.siit.io/guides/request-management/ticket-statuses.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.
