A messaging conversation is usually over a minute or two after the last message. The customer says thanks, the agent signs off, and the agent ends the session and takes the next chat. Some agents don't. They leave the session sitting open for ten or fifteen minutes after the conversation is done. While it is open it holds one of their concurrency slots, they look busy, and the next customer waits in the queue.

Qvasa measures this directly. For every messaging session it knows when the customer last wrote, when the agent last wrote, and when the session ended. The gaps between those moments show, agent by agent, who ends sessions promptly and who keeps them alive.

This article explains where that data comes from, what each metric measures, how to read them together, and how to build a dashboard for it.

A messaging session is one agent's turn in one messaging conversation, from the moment they accept it to the moment it ends. It is not the whole ticket. If a conversation is transferred from one agent to another, each agent has their own session.

The sessions come straight from Zendesk. When omnichannel routing hands a conversation to an agent, Zendesk emits agent work item events: the conversation was offered, the agent accepted it, the session ended. Qvasa receives those events in real time as they happen and turns each one into a work item status record. This is a row with the agent, the ticket, the channel, and the exact moment the session started and ended. Events that arrive late or out of order are stitched into the right place, so the start and end are correct even when Zendesk's feed is not perfectly in order.

These are the same records that power Qvasa's messaging concurrency, capacity and idle time metrics, so every number in this article reconciles with those.

The session record tells you when the session ended. To know when the conversation inside it was really over, Qvasa also streams in the messages themselves from the Sunshine Conversations interaction behind Zendesk messaging. Each message arrives with the moment it was written and who wrote it, and Qvasa stamps it onto the sessions it belongs to as it arrives:

The result is two timestamps on every session: the last end user message and the last agent message. A stamp only ever moves forward, so a message Zendesk delivers twice, or late, never moves it back. When a session closes, Qvasa re-checks both stamps against the messages it has stored.

Every metric below reads sessions that ended inside the dashboard's date range. Sessions that are still open are not counted. Each duration is available as an average and a median.

On this team, sessions stay open a median of 143 seconds after the customer's last message and 124 seconds after the agent's. The average after the agent's last message is 3m 45s, nearly twice the median. That gap is the first clue: a minority of sessions are being left open far longer than the rest.

To turn "too long" into a target, set the Messaging Session Last End User Message to End SLA under Settings → Service Level Agreements, in the Messaging group. It is a threshold in seconds (the default is 300, five minutes; any value from 1 to 86,400 is allowed). Each ended session with a customer message is compared against it on its own.

Once it is saved you get the whole SLA family: the within-SLA rate, within and outside counts that drill into the exact sessions, the rate and counts over time, and by-agent versions of each. The by-agent rate can also be added to a custom agent scorecard. A widget can override the threshold for itself, which is handy for comparing a five-minute bar with a ten-minute one side by side.

No one of these metrics tells the whole story on its own, and no single session proves anything. There are good reasons to leave a session open: a customer who says "one sec, let me find my order number", a follow-up the agent promised to confirm, a slow customer on a mobile device. Every agent on this team has a few sessions that ran 12 to 15 minutes past the last message.

What a large enough sample shows is a pattern. Compare agents by their median rather than one session or even the average. The median ignores the handful of legitimate long holds, so an agent whose median sits far above the team's is doing it routinely, not occasionally.

Here, six of eight agents end their sessions a median of 1m 38s to 1m 57s after their last message. Elena sits at 4m 21s. Marcus sits at 11m 55s, more than six times the team's norm, and he is the one worth a conversation.

The Agents table puts every measure side by side, so you can see whether the gap is consistent across all of them:

A few ways to read the combinations:

Watching the median over time tells you whether it is a habit or a bad week:

Every number leads back to the sessions behind it. Open the drill-in on any of these quick stats or donuts, choose the Work Item Status Records tab, and sort by Last Agent Message to Session End to see the longest-held sessions with all three timestamps:

Add the View in Zendesk column from Columns to open any session's conversation in one click, so a coaching conversation can start from a real example rather than a number.

Everything above is built with ordinary dashboard widgets. In the widget picker, search for last agent message to session end or last end user message to session end to find each family.

Agent and tag filters work on all of these, so you can build one dashboard per team or vendor.

These metrics need two things switched on for your account. The Qvasa team enables both:

If the widgets don't appear in the picker, reach out to your Qvasa contact to confirm both are enabled. The SLA widgets also need the SLA saved under Settings → Service Level Agreements first.