Email auto-merging

When a customer emails your support address, Octocom has to make a quick decision: is this part of a conversation we're already having, or is it something new? Getting this right keeps related messages together so agents see the full story, while still splitting genuinely unrelated issues into their own tickets.

This page explains how that decision is made.

Why merging matters

Customers don't always reply in a tidy way. Instead of hitting "reply" on our last email, they'll often start a brand-new email about the same issue — or reply to an automated message like an order confirmation, or write from a slightly different angle. Without merging, every one of those would become a separate ticket, and an agent would lose the thread of what's going on.

Merging stitches these stray emails back onto the conversation they belong to, so the history stays in one place.

The goal: keep one ongoing issue in one conversation, but don't accidentally glue two unrelated issues together.

The two kinds of incoming email

Every inbound email is sorted by one technical signal: the email's In-Reply-To header, which is set when a mail client replies to a specific message. That splits inbound mail into two paths, handled differently.

1. A direct reply to one of our emails

If the email's In-Reply-To header points at a message we actually sent, Octocom finds the thread it belongs to and, by default, adds the email to that conversation. This is the common case.

There's one extra check. If the matched conversation is closed, or the customer hasn't written in it for more than 72 hours, Octocom re-reads the new email against the conversation history and judges whether it's a continuation of the same issue or a genuinely new topic. If it's a new topic (for example, the old ticket was a refund that's long since done, and now they're asking about a new order), it starts a fresh conversation instead of reopening the old one. While the conversation is still open and recently active, this re-check is skipped and the reply is simply appended.

One exception: if your inbound email comes from a third-party help desk (Zendesk, Gorgias, Help Scout, Freshdesk, Re:amaze), Octocom trusts that system's own threading and never runs this re-check.

2. A brand-new email

This path covers emails that aren't a reply to one of our messages — either there's no In-Reply-To header at all, or the reply points at an automated/transactional email (like an order or shipping notification) rather than a real support thread. Here Octocom decides whether to merge the email into the customer's single most recent email conversation, or start something new.

The rest of this page is about that decision.

The decision tree for a brand-new email

Octocom walks through a series of checks against the customer's most recent email conversation. The email is merged only if it passes every one. If any check fails, the email starts a fresh conversation.

1. Is there a prior email conversation from this customer? We look up the customer's most recent email conversation, matched by their sender address. If they've never emailed before, there's nothing to merge into — new conversation.

2. Is that conversation still a reasonable size? If the customer has already sent 50 or more messages in it, we don't keep piling on — new conversation.

3. Is it handled by Octocom, not an outside help desk? If your inbound email runs through a third-party help desk (Zendesk, Gorgias, Help Scout, Freshdesk, or Re:amaze), we trust that system to decide its own threading and don't merge — new conversation.

4. Is the email coming in normally (not being auto-handed off)? If the email matches a rule that routes it straight to a human (by domain, address, or subject), we don't merge it — new conversation.

5. Is the existing conversation still "active enough"? An open conversation always qualifies, no matter how old it is — a thread that's been open for weeks is still available for merging. A closed conversation qualifies only if its last message was within the merge window — a per-mailbox setting that defaults to 72 hours (3 days). In other words, the window only matters once a conversation has been closed: a closed conversation that's been quiet past that window won't pick up new emails, and the email starts fresh.

   (One exception: if you run an external ticketing system, the "always open" rule doesn't apply — eligibility is based purely on the merge window, whether the conversation is open or closed.)

6. Is the new email actually about the same thing? Finally, an AI classifier reads the new email alongside the existing conversation and decides whether it's a continuation of the same topic or a new topic. Only continuations merge. If the customer has clearly moved on to a different issue, it becomes a new conversation.

If the email clears all six checks, it's merged into the existing conversation and the agent sees it as part of that ongoing thread. Otherwise, it starts fresh.

In short: a new email merges only when it's from a known customer, into a not-too-long, Octocom-managed, still-active conversation, and an AI classifier judges it to be about the same topic.

Contact form submissions

Contact forms don't arrive as emails, so a submission is never a "direct reply." Every contact form submission instead runs through the same brand-new-email decision tree above — it's matched against the customer's most recent email conversation and merges only if that conversation passes every check (not too long, still active, and judged to be the same topic). Otherwise it starts a fresh conversation.

Because a contact form isn't tied to a specific inbox, it follows your primary email mailbox's settings — including the merge window from step 5 and whether Octocom is set to handle conversations that customers start on their own. If that mailbox routes customer-initiated conversations straight to a human, contact form submissions are handed off and always start a new conversation rather than merging.

Things that are good to know

A few points that often come up:

• Merging happens within email only. If a customer starts a live chat on your website and later sends a separate email about the same thing, those two won't automatically merge — the logic only looks at the customer's previous emails. The two channels stay as separate conversations.

• The merge window is configurable. The window in step 5 is a setting on your email configuration (stored in minutes; default 72 hours). Shorten it if you want emails to split into new tickets more aggressively; lengthen it if customers often follow up days later about the same issue and you'd rather keep it together. Note this window applies to the brand-new-email path; the 72-hour staleness check on direct replies is fixed.

• The topic check leans toward keeping things together. Both the direct-reply re-check and step 6 use the same AI classifier, and it's deliberately cautious — it only splits an email out when there's a clear shift to a different subject after the previous issue looks resolved. If the classification can't be completed, it defaults to treating the email as a continuation. This avoids accidentally scattering one issue across several tickets.

• Nothing is ever lost by splitting. Even when an email starts a new conversation, the full history is still searchable, and a closed conversation reopens on its own if the customer replies to it directly.

• You can always merge by hand. The conversation sidebar has an Other Conversations section showing the customer's other threads, each with a Merge button. So if automatic merging splits something you'd rather keep together, an agent can join the threads manually.

A quick way to think about it

When a new email arrives, picture Octocom asking: "Is this a reply to something I sent, or a fresh email? If it's fresh, have I been talking to this person by email recently, is that conversation still warm, and is this message about the same thing?" When the answers line up, the email joins the existing conversation. Otherwise, it starts a new one.