> For the complete documentation index, see [llms.txt](https://en.help.firstline.cc/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://en.help.firstline.cc/feature/ticket/zhuang-tai-xi-xiang.md).

# Sub-status

Sub-status lets you further break down the current handling progress beyond the main ticket status, such as waiting for customer reply, waiting for internal confirmation, or issue resolved, making it easier for the team to understand the actual status of each ticket more precisely.

The ticket’s “status” indicates the main processing stage it is currently in, such as pending, in progress, resolved, or discarded; “sub-status” can further indicate a more detailed handling situation under the main status.

For example, even if tickets are all “in progress,” they may actually be in “waiting for customer reply,” “waiting for internal confirmation,” or “waiting for vendor processing.” With sub-statuses, the team can understand which stage it is stuck at more quickly without opening each ticket one by one.

{% hint style="info" %}
Sub-statuses do not replace a ticket’s main status; they are used to supplement more detailed progress under the main status. It is recommended to first plan according to the company’s existing ticket workflow, and then create sub-statuses that truly help determine progress.
{% endhint %}

## How can sub-statuses be used?

Common uses include:

* **Distinguish waiting reasons**: for example, waiting for the customer, waiting for an internal department, or waiting for a third-party vendor.
* **Indicate the current processing stage**: for example, contacted, pending testing, or pending manager confirmation.
* **Break down completion results**: for example, the issue has been resolved, the refund has been completed, or an alternative solution has been provided.
* **Help supervisors track tickets**: quickly determine from lists or reports which cases need follow-up.

## Sub-status examples

The following are only planning examples; actual names can be adjusted according to the company’s workflow.

| Ticket status | Sub-status examples               | Applicable scenario                                                                                                    |
| ------------- | --------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| Pending       | Waiting for first contact         | The ticket has been created, but no agent has started handling it yet.                                                 |
| Pending       | Pending assignment                | It has not yet been confirmed which team or agent should be responsible.                                               |
| In progress   | Waiting for customer reply        | The customer has been contacted, and we need to wait for additional information or confirmation from the customer.     |
| In progress   | Waiting for internal confirmation | Information is needed from another department, manager, or internal staff member.                                      |
| In progress   | Waiting for vendor processing     | The issue has been handed over to a third party or partner vendor, and we are waiting for the result.                  |
| In progress   | Testing confirmation in progress  | Processing has been performed, and it is necessary to confirm whether the issue has truly been resolved.               |
| Resolved      | Issue resolved                    | The issue has been handled and confirmed to be back to normal.                                                         |
| Resolved      | Refund completed                  | The ticket was completed through a refund or payment processing.                                                       |
| Resolved      | Alternative solution provided     | It could not be handled according to the original request, but an acceptable alternative was provided to the customer. |
| Discarded     | Duplicate ticket                  | Another ticket is already handling the same issue, so it will not be tracked separately.                               |
| Discarded     | No action needed                  | After confirmation, no further action is required.                                                                     |

{% hint style="info" %}
There is no need to create a sub-status for every minor situation. Too many sub-statuses will instead increase the cost for agents to choose. It is recommended to prioritize items whose names make it immediately clear what the next step is or where the issue is currently stuck.
{% endhint %}

## Create sub-status

You can enter ticket-related settings from the left menu in FIRST LINE and open the “Sub-status” management page.

You can add sub-statuses in the list or edit existing items. Each sub-status must be assigned to a ticket status, so the same sub-status will only appear under its corresponding main status.

### Basic settings

| Required | Field            | Description                                                            |
| -------- | ---------------- | ---------------------------------------------------------------------- |
| ✓        | Belonging status | Choose the main ticket status this sub-status should belong to.        |
| ✓        | Sub-status name  | Enter the sub-status name that agents will see in the ticket.          |
|          | Description      | Supplement the usage timing or internal definition of this sub-status. |

## Suggestions for planning sub-statuses

### The name should directly reflect the current progress

Rather than vague names like “In progress A” or “Other,” it is recommended to use descriptions that can be understood directly, such as “Waiting for customer reply” or “Waiting for logistics confirmation.”

### Avoid duplicating the main status

If the main status is already “Resolved,” there is no need to create a sub-status also called “Resolved.” Sub-statuses should provide additional information, not repeat the main status.

### Make sure the team has a consistent definition for each sub-status

If different agents interpret “Pending confirmation” differently, subsequent statistics and tracking will lose their meaning. It is recommended to add applicable conditions in the “Description” field, or clearly define in the internal workflow when that sub-status should be chosen.

### Regularly clean up items that are no longer used

When the ticket workflow changes, you can check whether there are duplicate, outdated, or rarely used sub-statuses to avoid the list getting longer and longer.
