# Hybrid ticket analytics: how to read the dashboard **This document is for** users who review extended ticket-based request analytics in the **`Statistics`** module **so they** choose the right time range, compare dashboard sections correctly, and avoid mixing different date semantics. --- ## Where to find it 1. Open the **`Statistics`** module: **Menu → Statistics**. 2. Go to the **`Dashboards`** tab. 3. In the list, select your organization’s custom ticket analytics dashboard. The Metabase title may include wording such as **“Hybrid ticket analytics”** (or the equivalent in your language). If several custom boards are available, ask your administrator which one is the extended ticket analytics view. General steps for viewing dashboards: [How to view Metabase dashboards in Statistics](../how-to/view-dashboards.md). --- ## Main idea: two different date logics The dashboard combines widgets that use **two period selection rules**. Mixing them when interpreting numbers leads to misleading conclusions. | Logic | Used in | What the selected range means | |--------|---------|------------------------------| | **Cohort by ticket creation date** | Overview, dynamics, service quality | The focus is on requests **created** in the selected range. Later events (reply, closure) still feed time metrics, but the **period filter** is “when the request arrived.” | | **Operator action day** | Operator productivity | The focus is what operators **did** in the selected range (messages, status changes, etc.). Ticket **creation** date may be any day. | **Rule of thumb:** analyzing flow and service speed — use cohort-based blocks. analyzing what the team actually did in a calendar window — use the productivity block. --- ## “Overview and dynamics” block (cohort by creation) ### Cohort summary A compact table of key figures for the period: how many requests **arrived**, how many reached **final closure**, **closure rate**, and **balance** (difference between closed and arrived — useful to see backlog build-up). Figures are for tickets **created** in the selected period. ### Created vs closed over time A line chart: one series is incoming requests by day, the other is how many of them are already **closed** according to your instance’s closure rules. If the “closed” line stays below “created,” backlog may grow. ### By weekday and by hour of day Bar charts show **when** requests in the period were **created** — by weekday and by hour. Use this for staffing and peak detection. If the widget splits by channel, compare each channel’s share of the flow. --- ## “Operator productivity” block (action day) These metrics reflect **activity in the selected calendar range**, regardless of when the ticket was created. ### Team summary Typical columns and plain-language meaning: - **Messages** — public operator replies sent in the period. - **Notes** — internal notes added in the period. - **Tickets with actions** — **distinct** requests the team touched with at least one action in the period. - **Touches** — simplified “work sessions”: one touch = one calendar day on a given request with at least one manual action (message or manual status change). Many messages the same day still count as one touch; returning on another day adds another touch. - **Created manually** — requests operators **created** in the period. - **Resolved** — distinct requests moved to a “resolved”-type status in the period. - **Closed** — distinct requests moved to a final closing status in the period. - **Closed with one message (%)** — among closures in the period, the share closed after exactly one relevant public operator message (automated/service message types are usually excluded — see the widget hint). - **Average messages per ticket** — how “chatty” handling was on average. ### Per-operator breakdown The same kinds of metrics **per operator** — useful for load and style comparison. --- ## “Quality” block (cohort by creation) All quality metrics apply to **tickets created** in the selected period. First reply or final close may happen later; they are only used to compute durations. ### Average times (table) - **FRT (first response time)** — from request creation to the operator’s **first** reply. - **SRT (second response time)** — from creation to the **second** operator reply (often reflects pace after the conversation starts). - **ART (average response time)** — from a client message to the next operator reply during the dialogue. Several client messages in a row with the same timestamp are often grouped; the clock uses the **last** message in the group. - **TTC (time to closure)** — from creation to transition to the **final closing** status. Tables usually show **median** and **average**: - **Median** — typical experience for “most” requests; less sensitive to a few very slow cases. - **Average** — reflects long tails; can move more when outliers exist. ### Range charts (brackets) Horizontal bars show the **share** of requests in each time bucket (e.g. under 10 minutes, 10–60 minutes, and so on). For **FRT** and **SRT**, there is often a **“No reply yet”** category. For **TTC**, **“Not closed”** may appear for requests not yet in final closure. **ART** bracket charts usually do **not** include a “no reply” bucket, because the metric is defined only where client–operator turns exist. If drill-through to a ticket list is configured for a bar, use the click action available in Metabase for that card. --- ## Filters and hints - **Dashboard filters** (dates, bot, topic, channel, etc.) may be wired only to some cards. If a filter does not change a section you expect, ask your administrator — different widgets need different date bindings. - Card-level **descriptions** are often stored in Metabase — use the **“i”** icon next to the question name when viewing in Metabase. --- ## Related articles - [How to view Metabase dashboards in Statistics](../how-to/view-dashboards.md) - [How to apply report filters](../how-to/apply-report-filters.md) - [Statistics metrics — reference](../reference/statistics-metrics.md)