Avoiding Duplicate Replies in a Shared Support Inbox
Two people reply to the same customer email at the same time by opening the same conversation and typing at the same time, with no signal to either one that the other is already in there. The tools built for shared inboxes solve this with real-time presence. Front and Help Scout both show a live indicator the moment a teammate opens a message someone else is already answering, so the second person sees it before they hit send instead of after. Plain shared mailboxes without that layer, like a Gmail delegation setup or a bare Google Group, have no such indicator at all, and lean on an assignment habit instead.
Which one you get depends entirely on which tool is holding the inbox. Front's documentation describes the live warning and stops there; Help Scout's documentation goes a step further and spells out what happens if you send anyway.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionWhat Front actually shows you
Front calls this real-time collision detection, and it works the way the name suggests: "if a teammate is working on a message in a shared inbox, you will see indicators that they are replying," and draft content is shared and updated as the other person types it, not just on save. Open a conversation someone else already has open, and you see them there before you start typing your own reply.
That's a warning, not a documented lock. Front's help center describes only the live indicator. It doesn't say anywhere what happens if you see it and send anyway. The complementary habit is assigning the conversation to one person, which "can only be assigned to one user at a time." A team that assigns on open and treats an unassigned conversation as unowned catches most collisions before the live indicator ever has to.
What Help Scout does differently
Help Scout's collision detection shows the same kind of presence signal, a colored icon in the folder list and colored avatars inside the conversation, yellow for viewing, red for actively replying or noting. What Help Scout documents beyond that is a specific answer to what happens if you send anyway while someone else has already replied. Help Scout holds your outgoing message in a "Needs Attention" folder with a paused status instead of delivering it, and asks you to send it as-is, edit it, or discard it. Front's own documentation doesn't describe an equivalent. It covers the live indicator and stops there, with no mention of a post-send catch.
Neither behavior is configurable in any meaningful way. Help Scout's own guidance calls the feature one that "runs quietly in the background," and turning it off isn't something either vendor recommends.
What a plain shared mailbox gives you instead
Not every shared support@ address lives inside Front or Help Scout. A lot of small teams run it as a Gmail delegation or a Google Group, and Google Groups' collaborative inbox has no live presence layer at all. What it has is assignment ("assign responsibility for a conversation to yourself or another group member") and a set of resolution tags you apply by hand, including one literally called Duplicate, for marking a thread that turns out to repeat another one. Both are useful, and both are after-the-fact bookkeeping rather than a signal that stops a collision as it's happening. On a plain shared mailbox, the entire defense is the team's own discipline about claiming a thread before answering it.
The Thornfield Analytics near-miss
Thornfield Analytics is a four-person analytics dashboard company running its support@ inbox through Front. Fintan Rooksby handles most of it alongside two teammates who split in when volume spikes.
A customer emailed asking why their weekly export had stopped including a column they'd relied on for a finance report. Fintan opened it, started drafting an explanation of the schema change behind it, and got pulled into a call. Twenty minutes later, a teammate named Anneke opened the same conversation to help clear the afternoon backlog.
Anneke, in the team's Slack channel: "Front's showing Fintan's avatar with the red ring on the export ticket, so I'll skip that one and take the two under it instead."
The collision indicator did exactly its job there, turning a possible double-reply into a two-second decision. But the same customer had also opened a ticket in the Zendesk queue Thornfield hasn't fully retired since migrating to Front, asking the identical question in different words, and a teammate working that queue had already answered it without knowing support was on the Front thread too. Front's collision detection had nothing to say about that, because the collision wasn't inside Front. It was between Front and a channel Front can't see.
Where collision detection stops working
The indicator, the pause, the assignment habit. All three only operate inside the one system that's watching. None of them know:
- That the same customer also emailed a different alias, or DMed an AE on Slack, or opened a ticket in a second tool the team keeps around from before the Front migration.
- That a request answered fully in one channel is the same request sitting half-drafted in another.
- That "who replied" and "was this the same ask" are different questions, and collision detection only ever answers the first one.
For a small team on one inbox with clean habits, that ceiling rarely gets hit. It starts showing up once support runs through more than one surface, like a shared inbox plus Slack Connect channels with a few accounts, or a shared inbox plus a ticket form that isn't wired into it. At that point, avoiding a duplicate reply stops being about presence indicators inside one tool and becomes about knowing a request already has an answer somewhere else entirely.
This is the point in the guide where Modem enters, since it's built by the same team writing this. It isn't a reply tool, it doesn't sit inside the send button, and it won't show you a colored ring around someone's avatar. What it does is watch connected email alongside Slack, tickets, and calls, read what each message is actually asking, and collapse the ones that are the same underlying request into one topic with every channel it arrived on and every reply it already got attached. Fintan wouldn't need Anneke's heads-up to avoid a duplicate; the export question would already show the Zendesk answer sitting on the same topic before either teammate opened the conversation. We build Modem, so weigh this recommendation the way you'd weigh any vendor recommending itself. The collision detection above is free, built into the tool you already pay for, and correct for the problem it's built to solve, but it isn't built to solve the cross-channel version.
Two related guides worth reading if this is where your inbox is headed: routing support emails when account ownership data lives outside the inbox, and applying tags retroactively to old support emails in Front if the backlog itself is the problem, not just today's incoming volume.
The smallest version you can start this week
If your shared inbox runs through Front or Help Scout, confirm nobody on the team has muted or dismissed the collision indicators, since both platforms let notifications get buried without turning the underlying feature off. If it's a plain Google Group or a delegated Gmail account, write down the one-line rule Thornfield already runs on informally. Assign before you draft, and treat an unassigned thread as unclaimed. That single habit closes most of the gap a live indicator would otherwise cover, and it costs nothing to start today.
