Agent Wise Conversation States Table
This section explains how agent-level ticket activity is reported in the Agent Wise Conversation States table.
It defines the columns, how counts are calculated, and how status can be viewed in two different modes:
Current State (As of Today)
State at the End of the Selected Time Period
This distinction is critical for managers and admins who want to answer two different questions:
“What did this agent do during this period?”
“Where do those tickets stand now?”
1. Updated Terminology & Definitions
1.1 “Handled” → Handled Tickets
We are renaming the header “Handled” to Handled Tickets for clarity.
Handled Tickets =
All tickets the agent worked (status changed, assigned) on during the selected time period, including:
Tickets that were created before the selected time period but were still active and assigned to the agent during the period (“carry-forwarded tickets”)
Tickets that were newly assigned during the selected period
This means Handled Tickets is not just “new work”, it’s “all work touched”.
Why this matters:
Managers can see true workload, not just new volume.
1.2 Carry-Forwarded Tickets
Carry-forwarded tickets are tickets that:
Were created before the selected time range
Were not yet resolved at the start of the selected time range
Were actively assigned to / handled by the agent during the selected time range
These tickets count toward Handled Tickets.
This prevents undercounting agents who inherited older backlog rather than just new tickets.
1.3 Reopened Tickets / Reopen %
Reopened = The number of tickets that were reopened (moved from a resolved/closed state back to an active state) during the selected time period.
We may also show Reopen % in addition to the raw count.
If enabled, Reopen % would represent the share of handled tickets that had to be reopened.
Interpretation:
A high reopen count and/or % can indicate quality issues in resolution.
This can be used for coaching and QA.
(This behaviour is subject to product decision. If Reopen % is not shown, “Reopened” will still reflect the reopen count.)
1.4 Number of Resolutions
Number of Resolutions = Total number of resolution events performed during the selected time period.
Important:
This is a non-unique count of resolutions.
The same ticket may contribute multiple times if it was resolved multiple times in that period.
This metric is assignee-agnostic: it counts resolution actions regardless of which agent was assigned at ticket creation.
How to interpret:
This shows “how many times we took something to a resolved state,” not “how many unique tickets were resolved”.
This is useful for understanding effort/output, not final backlog.
1.5 Status Buckets (Open, Waiting, Follow-up, Resolved, Closed)
These status columns refer to the state a ticket is in:
Open – The agent/brand owes a reply or action.
Waiting – Waiting on the customer.
Follow-up – Requires future action / scheduled follow-up.
Resolved – Marked resolved but not necessarily permanently closed.
Closed – Fully closed / ended.
These statuses can be reported in two different timelines:
As of “right now” (Current State)
As of “the end of the selected time period”
That distinction is documented below.
2. Why We Have Two Views
Managers typically need to answer two different questions:
2.1 Work Done Analysis (End of Period View)
“What was the outcome of the work in this period?”
Example:
Between Sept 1–15, how many tickets did Agent A end that period with in Open / Waiting / Resolved / Closed?
This is useful for retrospective performance reviews and SLA compliance over a defined reporting window.
We call this mode:
State at the End of the Selected Time Period
2.2 Current Status Tracking (Live View)
“Where do things stand right now, for the tickets this agent touched during that period?”
Example:
Looking at Sept 1–15 work: Which of those tickets are still open today?
This is useful for live ops / daily standups to identify backlog and handoffs.
We call this mode:
Current State (As of Today)
3. UI Behavior: Status Mode Switcher
In the Agent Performance table view:
There is a Switcher that lets the user choose which status view they want to see:
Current State (As of Today)
State at the End of the Selected Time Period
The table is visually split into two logical sections:
Section 1: Summary Metrics (always static; does not change with the switcher)
Section 2: Ticket Status View (changes based on the switcher)
Only the Ticket Status View section is affected by the switcher.
This allows admins to move between “operational now” and “snapshot then” without losing the high-level summary.
4. Table Layouts
4.1 Table 1: Summary Metrics (not affected by the switcher)
Agent Name
Name of the agent.
Handled Tickets
Total tickets handled during the selected time period, including carry-forwarded tickets.
New Assigned
Number of tickets newly assigned to this agent during the selected time period.
Reopened
Total number of tickets that were reopened during the selected period.
Number of Resolutions
Total number of resolution events performed in the selected period (non-unique, assignee-agnostic).
Notes:
“Handled Tickets” reflects true workload, not just new tickets.
“Number of Resolutions” counts resolution actions, not unique tickets.
Optional:
“Reopen %” may be displayed alongside Reopened if enabled.
4.2 Table 2: Ticket Status View
This table shows how tickets are distributed across lifecycle states (Open, Follow-up, Waiting, Resolved, Closed).
The columns are the same, but the meaning of the numbers changes depending on which mode is selected.
Case A. Current State (As of Today)
This mode answers:
“For tickets the agent handled during the selected period, what is their status right now?”
Agent Name
Name of the agent.
Open
Number of those tickets that are currently open today.
Follow-up
Number of those tickets that are currently in follow-up today.
Waiting
Number of those tickets that are currently in waiting today.
Resolved
Number of those tickets that are currently in resolved state today.
Closed
Number of those tickets that are currently fully closed today.
Key point:
This is “live backlog status today,” filtered to only the tickets this agent touched in the selected time range.
Case B. State at the End of the Selected Time Period
This mode answers:
“At the end of the chosen reporting window, what state were those tickets in?”
Open
Tickets that were still open at the end of the selected time period.
Follow-up
Tickets that were in follow-up at the end of the selected time period.
Waiting
Tickets that were in waiting at the end of the selected time period.
Resolved
Tickets that were in resolved state by the end of the selected period.
Closed
Tickets that were closed by the end of the selected period.
Key point:
This is a historical snapshot. It does not change based on what happened after the period ended.
5. How to interpret these views
Use State at the End of the Selected Time Period to measure how effectively an agent closed or progressed work during a defined reporting window.
Example: “By end of Sept 15, how much work did they leave open?”
Use Current State (As of Today) to understand ongoing operational load from that same work.
Example: “Of the tickets this agent touched last week, which ones are still sitting open today?”
Together, these tables let you audit both:
Historical performance in that window
Ongoing backlog linked to that agent’s work
6. Summary of key changes
“Handled” is now explicitly called Handled Tickets, and it includes carry-forwarded tickets so inherited backlog is not ignored.
We may introduce Reopen % in addition to raw “Reopened” count to evaluate quality of resolution.
Number of Resolutions is a non-unique count and is not tied to a single assignee. The same ticket can contribute multiple times.
Status (Open / Waiting / Follow-up / Resolved / Closed) can be viewed in two different modes:
Current State (As of Today)
State at the End of the Selected Time Period
This model supports both performance review and live backlog management without requiring external reporting.
Last updated