> For the complete documentation index, see [llms.txt](https://help.zaapi.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.zaapi.com/analytics/ticket-fields.md).

# Ticket fields

Analyze how your **ticket fields** are filled in — the distribution of values across resolved tickets, and how each value trends day to day. Pick a field (a category, a product segment, a reason code, anything you track on tickets) and the page shows you what customers' tickets were actually about.

It's period-based and follows the shared rules in How we calculate analytics.

***

### The key rule: values are snapshotted at closure

**A ticket field's value is captured at the moment the ticket closes** — that's the value this page counts. Whatever the field held earlier in the ticket's life is ignored; only its value at resolution matters.

Why it works this way: a field like *Reason* or *Product Segment* often gets set, corrected, and refined while a ticket is being worked. Snapshotting at closure gives each ticket a single, settled answer, so the numbers are stable and a ticket is never counted twice or under a value it briefly carried mid-conversation.

Two consequences worth knowing:

* **Only closed tickets appear here.** An open ticket hasn't been snapshotted yet, so it isn't counted. Like Closed Tickets and Resolution Time, this page is anchored to **closure** — a ticket lands in the period on the day it closed.
* **A ticket counts once**, under the value it held at closure, on its closure date.

**Example.** An agent opens a ticket, sets *Enquiry Type* to `Product`, later refines it to `Refund`, then closes the ticket on Jun 3. It's counted once — under `Refund`, on Jun 3. The earlier `Product` value isn't counted.

***

### How to use the page

1. **Pick a field** from the *Field* selector at the top (e.g. `Enquiry Reason`).
2. The **All values** panel lists every value that field held at closure, with a total count.
3. **Tick up to 10 values** to plot them on the **Trend** chart and compare them over time.

***

### All values

A table of every distinct value the selected field had at closure during the period, with a **Total** — the number of tickets that closed with that value.

Values can be **hierarchical** (e.g. `Product > LG > Phone`), and each distinct value is counted exactly as it was stored. A ticket closed with the field set to just `Product` is a *different* value from one set to `Product > LG` — they're listed and counted separately, with no roll-up of children into their parent.

***

### Trend

A line chart showing the **daily count of each selected value at the moment of closure**, across the selected period. Tick values in the All values panel to add them (up to 10); each appears as a line with a colour in the legend, and you can remove a line from the legend's ✕.

Because it's plotted by closure date, the Trend chart answers "how many tickets closed with this value each day?" — useful for spotting a spike in a particular product, reason, or segment over the week.

***

### Filters and controls

* **Date period** — the window the page is calculated for (shown as both the preset, e.g. *Last 7 days*, and the resolved range).
* **Field** — which ticket field you're analyzing. Clearing it returns the page to the empty "Select a field" state.

***

### What happens if a ticket field is changed after closure?

If a ticket field is updated after closure, it will be updated and backfilled in the analytics, replacing the ticket field that was updated.

***

### What happens if a ticket is re-opened and then ticket fields are changed?

If a ticket is re-opened and is in the open state during the selected time period, it will not show in the ticket fields dashboard until it is closed again.

***

### Good to know

* **Only resolved tickets are here** — values are captured at closure, so open tickets don't appear.
* **Counted once, at closure** — see the rule above.


---

# 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 dynamically by asking a question.

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

```
GET https://help.zaapi.com/analytics/ticket-fields.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.
