Who is actually carrying the ticket load, and how long are members waiting? Open Staff, then Performance and the numbers answer both.
The signals
For each staff member over the last 7, 30, or 90 days, or over one calendar month:
- Closes. Tickets they resolved. Only staff-closed tickets count; AI resolutions, member self-closes, inactivity closes, and dashboard force-closes never inflate anyone's numbers.
- Replies. Counted per turn: consecutive messages from a staff member count as one reply, and a new one is counted only after the ticket opener responds.
- First reply. How long the ticket sat before this person said their first word in it, counted from the moment staff could actually see it. For a ticket the AI triaged, that is when it escalated to staff, not when the member opened it, so the AI's own handling time is never charged to your team.
- Reply time. Every stretch a member spent waiting, not just the first one. A wait starts at the member's earliest unanswered message and ends at the first staff reply that answers it, and that reply's author gets the sample. An AI answer ends the wait without counting as a staff reply, so it scores for nobody, and a second staff member joining a reply already in progress scores nothing either.
- Time to close. From the moment the ticket opened to the moment it closed, over every ticket credited to this person, claimed or not.
Picking the window
The 7, 30, and 90 day segments are rolling: they count back from right now. Month switches to a calendar month picker covering the past year, so you can answer "how did the team do in August" rather than "how did the last 30 days go". Months run on UTC boundaries, exactly as the payroll report counts them, so the closes you see for a month here are the closes payroll priced for that month (less any categories excluded from pay).
Medians, with the average beside them
Each of the three timings shows a median on the line with the average underneath, and the median is the one to read. A handful of tickets that sit open over a weekend drag an average many times above the median, which is how a team whose typical first reply is about a minute ends up showing an average over an hour. The gap between the two numbers is itself the signal: a median far below the average means most tickets are fast and a few are stuck.
Avg claim to close is gone. It measured from the claim rather than from the member's problem, and it was blank for every ticket nobody claimed, which is most staff closes. Time to close replaces it and counts the whole ticket, whether it was claimed or not.
Reply time needs stored transcripts
Reply time and the reply count are read from the ticket messages themselves. If Transcript retention is off on Tickets, then Settings, nothing is stored, so replies cannot be counted or timed and the Reply time column is not shown at all. Closes, first reply, and time to close are unaffected: they are computed from the ticket record, not its messages.
The same numbers in Discord
Staff who never open the dashboard get the same figures from /mystats: closes, replies, median first reply, and median time to close, for the last 24 hours, the last 7 days, and the current month. It is a private reply, visible only to the person who ran it.
Attribution
Credit for a close goes to whoever claimed the ticket, or to the closer when nobody claimed it. You can change this rule on the Payroll page, and both pages read the same rule, so credit never differs between them.
Two things do differ. Any categories you exclude on the Payroll page drop out of pay totals but still count on Performance, so a staff member's closes here can be higher than the closes they were paid for. And with Split closes by contribution turned on there, payroll splits a close among the staff who replied in the ticket by reply turns, while the close here stays whole with the claimer, else the closer. Both are deliberate: Performance measures work done, payroll measures work you pay for.
Reading it fairly
Numbers are signals, not verdicts. Pair them with member reviews before drawing conclusions: fast but sloppy and slow but loved look identical in a closes column.