Best practices for handling customers who reply to old archived threads with new requests

We've dealt with a similar issue, and one approach that has worked well for us is treating older reopened conversations as "new work" unless there's clear evidence that the customer is continuing the original issue.

Our workflow uses a rule that checks whether a conversation was previously archived and inactive for a defined period. When a reply arrives after that threshold, we automatically apply a tag indicating that the conversation needs review and route it to a shared triage inbox rather than returning it directly to the previous assignee.

This has helped for a few reasons:

• The original owner may no longer be the best person to handle the request.
• Customers often change topics within old email threads, making historical context less relevant.
• A triage step ensures that genuinely new requests are categorized and assigned correctly.

We've also found it useful to track these conversations separately in reporting. Over time, the data showed that a significant percentage of "reopened" conversations were actually brand-new requests submitted through old email chains. That insight helped justify additional automation and process changes.

One lesson learned is to avoid fully automating reassignment based solely on a reopened status. In our experience, some replies are legitimate follow-ups to unresolved issues, so having a quick triage review before assignment improved accuracy.

I'd be interested to hear whether other teams are using message content, AI classification, or custom fields to help distinguish between a true follow-up and a completely new request.

Hi there!

This is a super common pattern in email-based support: a customer hits “reply” on an old thread, but their intent is effectively “new ticket.” The cleanest way to handle it in Front is to (1) make sure “old thread reply = new segment/new conversation for analytics,” and then (2) use routing rules so the reopened work reliably lands back in triage (not back on the prior owner).

Recommended setup (practical + scalable)
 

1) Use Close conversations to force “old reply = new conversation segment”

Front has a dedicated setting to automatically close conversations after a period of inactivity, specifically to prevent unrelated new topics from being lumped into the same long thread (and to keep analytics consistent). This is the foundation for accurately tracking how often customers “start new requests via old threads.”

Help Center: Set tickets and conversations to close automatically for more consistent analytics.

Why it matters for your goals:

• Analytics: Once the inactivity window has passed, new activity is treated as a new conversation (segment) rather than a reopened one (depending on your analytics definitions and inactivity window). The “Reopened conversations” glossary explicitly notes this behavior.[2]
• Operations: It reduces the “old context + old owner” problem because you’re intentionally telling Front “this thread is done; anything later is new work.”

2) Route “replies on archived/closed threads” back to Unassigned triage

In Front, archived conversations automatically reopen when there’s new activity.[3] The key is making sure reopened activity doesn’t quietly land back in someone’s personal/assigned flow.

Two common approaches:

• Rules-based triage: Use rules with triggers/conditions around conversation status (archived/reopened) to push the conversation to an unassigned queue for re-triage. Front documents the available rule triggers, including status-based ones like “Conversation is archived” and “Conversation is reopened” (with an important caveat described there about what “reopened” includes/excludes).[4]
• Segment-based behavior (preferred when available): If you implement “Close conversations,” then replies after the inactivity threshold are much more likely to behave like new work operationally/analytically—so your routing rules can be simpler and more reliable.[1]

3) Tagging structure: separate “true reopen” vs “new request on old thread”

What high-volume teams tend to do is tag based on time + intent:

• Reopen – same issue (short time window; e.g., within X hours/days of resolution)
• New request – old thread (past inactivity/close threshold)

You can still keep your proposed tag like “Reopened – Review Required”, but I’d strongly consider splitting it into two tags so your reporting/actionability is clearer:

• Reopened - Same issue (quality signal: “did we not resolve it?”)
• New request - Old thread (channel behavior signal: “customers don’t start new threads”)

That split aligns nicely with how Front frames “reopened conversations” as a potential signal that the initial response didn’t meet the need.[2]

Measuring it (so you can quantify the problem)

• Use the Reopened conversations metric as a baseline volume signal.[2]
• If you adopt the 2-tag approach above, you can then report on “new request on old thread” via tag-based reporting (and keep “true reopen” as a QA/deflection-quality signal).

What other teams are doing 

There’s an active Community thread specifically about customers replying to old archived threads and wanting those to return to unassigned for triage.

Hope this helps!