Conversation Event Tracking Timeline | Community
Skip to main content
Submitted

Conversation Event Tracking Timeline

Related products:ReportingData
  • June 27, 2025
  • 1 reply
  • 28 views
B

I’d love to submit a feature request that would enhance conversation analysis capabilities—particularly for chat, email, and social channels.

It would be incredibly useful to have a more granular, timeline-style view of all key events within a conversation—from when it was opened (on the left) to when it was closed (on the right), highlighting all the specific events and triggers that took place during that conversation in between. Something similar to the "Show conversation events" toggle, but expanded to highlight specific backend actions and metrics. For example:

  • When an SLA workflow was triggered

  • When the conversation was snoozed/opened/closed/reassigned

  • When handle time started and stopped

  • The calculated SLA and total handle time for that conversation

This detailed visibility would be extremely helpful for digging into complex or edge-case conversations and understanding exactly what happened and when. It would also go a long way in helping teams diagnose and optimize support workflows with greater confidence. 

Thanks so much for considering this!

1 reply

A

Seconding this.

I spent a week going back and forth with support trying to work out why an SLA applied to one conversation, and almost all of that time was lost to the conversation timeline showing me event placements that cannot be reconciled with what actually happened.

I would like two things: a real timestamp on every event, and the reasoning behind the event.

The problem

Some system events are not stamped with the moment they were recorded. They are stamped with a calculated reference time. SLA events are the clearest case: an "SLA applied" event carries the reference time the reply clock was anchored to, and an "SLA missed target" event carries that anchor plus the target duration. Because the timeline sorts on those stamps, the events land wherever the calculation puts them, which can be hours earlier and even on the previous day. The result is a timeline that renders sequences that are not possible. On my conversation, the row SLA: "Tier 4" missed next response target appears roughly fifteen hours ABOVE the row that applied that same SLA. A breach is displayed before the SLA it belongs to exists. Two other SLA rows sit on the previous evening, above the close event, when the underlying records were written the following morning.

Nothing in the UI marks any of these as calculated rather than observed. I only established what really happened by pulling the conversation through the API and sorting the conversation parts by part ID instead of by timestamp. That should not be the supported way to read a timeline.

What I would like

1) Show both timestamps on every event. When an event carries a calculated or reference time, show the time it was actually recorded alongside it, for example "recorded 09:46:46, reply clock anchored to 17:20:14 (previous day)". If only one can be shown, show the recorded time.

2) Order the timeline by recorded time, or clearly flag events that are placed by a calculated stamp so it is visible that they are out of sequence.

3) Never render a "target missed" event above the "applied" event for the same SLA. That ordering is always wrong and it sends people looking for causes that do not exist.

4) Add reasoning to the event itself. For an SLA event I want to see, without opening a support ticket: which workflow or rule applied it, which step inside that workflow, which condition matched and on what value, and which reference time the clock was anchored to. The same applies to assignment, tag, and state-change events — the timeline currently tells me an event happened but never why it happened.

5) State whether backdated SLA events are counted in SLA and breach reporting. If they are, a breach that never occurred live is inflating our numbers for the day it is displayed on, and there is currently no way for a customer to tell.

Why this matters

Workflow debugging depends entirely on this timeline. When the ordering is not trustworthy and there is no attribution on the events, every investigation turns into a multi-day exchange with support in which both sides are reading the same screen and reaching different conclusions.

Points 1 and 4 would have resolved my case in about five minutes.

Terms & ConditionsAccessibility statement