Handling time affected by Snooze

Hey ​@Lawrence Toh 

What you’re seeing is expected behaviour, but I agree it’s not ideal for teammate-level handling time.

Here are some workarounds you could consider:

1. Route auto-close flows away from human assignees
   Just before you snooze for auto-closure, reassign to a neutral team/teammate used only for automation, e.g.:

   Assign to team "Automation" → Snooze (4 hours) → Closing message → CSAT → Close

   That way, the final few seconds of “handling” live on a bot/automation owner, not on another human teammate.

2. Avoid auto-reassignment on unsnooze where possible
   If the goal is for Anthony to “own” the conversation end-to-end, keep them in Away (not “Away & reassigning”) and/or adjust assignment limits so the conversation isn’t reassigned when the snooze ends.

3. Use Adjusted handling time (if enabled)
   If your workspace has Adjusted teammate handling time turned on, you can base performance views on that metric. It excludes idle time between “ready” events (assign/unsnooze/reopen) and when a teammate actually resumes work, so teammates who never open the conversation again will show ~0s adjusted handling time for that leg.

Thanks Dara for the response!

While Point 1 would no doubt work, it is not feasible to implement because we have reports with individual charts using different “Team currently assigned” filters. This would likely require substantial changes to the reporting system.

For Point 3, the AAHT only removes idle time from Bryan (as he is not actively viewing the reassigned conversation for at least 15 seconds before the bot sends an automated message and closes the conversation). However, it would still count as one conversation leg with 0 seconds handling time, and averages are calculated based on total conversations. This would still reduce Bryan’s average handling time.

Point 2 is a great suggestion. We always use “Away & Reassigning,” which may be causing the system to reroute the conversation to another agent after the snooze timer ends and before the assignment action within the workflow is triggered.

Hi ​@Lawrence Toh 👋 I’ve faced similar challenges with the reporting and get the pain point. 

Point 1) In the same workflow, would you consider adding a tag to the conversation so it would be excluded from the reporting? Or do you absolutely have to have all conversations included?

Hi ​@Aleksei O 👋 If we were to add a tag to exclude those conversations from the report, wouldn’t these also be removed for the original assignee? If so, this would result in inaccurate handling time metrics.

This is a known quirk with how Intercom handles snooze-based reassignment. The re-assignment that happens when a snooze expires is triggered by the inbox routing rules (assignment limits, away status), and it fires before your workflow actions resume, which is why your "Assign to Catherine" step can't override it. There is no native way to suppress that intermediate assignment today.

The workaround most teams use is to restructure the workflow so the closing sequence is not dependent on snooze at all. Instead of snoozing and then closing, you can use an inactivity timer tag or a webhook to a short automation that fires the closing message directly without going back through the assignment queue. Another option is to unassign the conversation before the snooze step rather than assigning to a specific person, so the snooze expiry has no assigned owner to override. That does not fully eliminate the ghost assignment problem but reduces how often it touches a real teammate's metrics.

On the reporting side, the cleanest fix is to filter handling time reports to exclude conversations where the agent sent zero messages. Intercom's native reports do not give you that filter easily, but you can export the data and apply it in a spreadsheet. (Disclosure: I work on Velax, an analytics layer on top of Intercom at https://velax.ai that can filter agent metrics by whether the agent actually replied, which addresses exactly this ghost-assignment problem.)

Worth raising with Intercom support too since the snooze reassignment behavior feels like something they should expose a setting for.

Agreeing with the points raised by Ilija above! 

​@Lawrence Toh You are right that in this case, the conversation will also be removed from the original assignee. Taking into account a very good description above, my thought was just to tackle these as “edge cases” and assume the majority won’t be in this basket. 

That said, could you give me your definition of the “handling time” metric in your report? Maybe there is another way...