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

Open the Statistics module: Menu → Statistics.
Go to the Dashboards tab.
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.

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.