It happens in the first hour of the morning, usually. A client writes in with a question. Two people open it at roughly the same time, both think nobody else has picked it up, and both reply. The client gets two answers four minutes apart, and if the answers do not match, they now have a question about your team rather than about their work.
Everyone who has run a shared mailbox has done this. It is the single most common failure mode in team email, and it is not a discipline problem. Plain Gmail and plain Outlook give you no way to see that a colleague is in the same thread right now, so the only defence is talking to each other, which does not scale past about four people or across a single time zone.
Plain Gmail and Outlook have no built-in way to show that someone else is drafting. You need either a shared inbox tool with collision detection (Sektra, Front, Hiver, Missive, Help Scout and most others have some form of it) or a manual claiming convention. Tool-based detection is the only version that works reliably, because it does not depend on anyone remembering to do anything.
Is there a Gmail add-on that shows when someone else is replying?
Yes, several, though what they show varies more than the marketing suggests. Gmail itself has nothing for this. Google Groups collaborative inboxes let you assign a conversation, but assignment is a deliberate act after the fact, not a live signal while someone is typing. So the answer is always an add-on or a separate tool.
The versions you will find fall into three groups, and it is worth knowing which one you are buying.
- **Presence indicators.** The tool shows an avatar or a small label on the thread when a teammate has it open. This is the lightest version and the most common.
- **Draft-level warnings.** The tool detects that someone has started typing a reply, not just that they opened the thread, and warns anyone else who tries to do the same. This is the one people actually mean when they ask for it.
- **Locking and assignment.** The thread has a single owner. Others can read it, but replying requires taking ownership first. The strictest option, and the one support teams tend to prefer.
Presence alone is weaker than it sounds. Someone can have a thread open in a background tab for twenty minutes without touching it, which trains the team to ignore the indicator. If double replies are a real cost for you, ask the vendor specifically whether the signal fires on opening or on typing.
Which shared inbox tools have collision detection?
Most of them, at some level. The table below covers where the feature sits in each product, based on public documentation checked in September 2026. Behaviour changes between tiers, so confirm on your plan rather than on the marketing page.
| Tool | What it shows | Where your team sees it |
|---|---|---|
| Sektra | Live indicator when a teammate opens or starts drafting, plus thread ownership | In Sektra, synced with Gmail, Outlook and WhatsApp |
| Front | Presence and draft indicators, plus assignment | In the Front app |
| Hiver | Collision alerts and assignment status | Inside the Gmail interface |
| Missive | Live presence and shared drafts several people can edit | In the Missive app |
| Help Scout | Viewing and typing indicators on a conversation | In the Help Scout app |
| Gmelius | Presence on shared labels and assigned conversations | Inside the Gmail interface |
| Google Groups | None. Assignment only, after the fact | In the Groups web interface |
The third column is the one people underweight. If half your team is working in Gmail and the tool only shows the signal inside its own separate application, the people most likely to cause a collision are the ones who will never see the warning. That is the practical argument for tools that either live inside Gmail or sync with it two ways.
How do you stop double replies without buying a tool?
You can get most of the way there with a convention, provided the team is small and works overlapping hours. Three that work in practice.
- **Claim in a channel.** One Slack or Teams channel where you post the subject line before you start typing. Crude, and it works for a team of four. It stops working the moment someone is heads down and forgets.
- **Label as a lock.** In Gmail, a shared label such as `handling/lena` applied before you reply, removed when sent. Visible to everyone in the mailbox, and requires no extra tool. It depends entirely on people applying it first, which is exactly the moment they are least likely to.
- **Rota by hour.** One named person owns the inbox for a block of the day and is the only one who replies. Everyone else can read. This is the most reliable manual option, and the least popular, because it makes one person responsible for a queue they did not choose.
Every one of these fails the same way: it depends on a person doing something before they do the thing they actually want to do, which is answer the client. That is why teams that grow past a handful of people end up buying something instead.
Why assignment on its own does not solve it
A lot of teams buy a shared inbox, turn on assignment rules, and assume the problem is handled. It usually is not, for a reason worth spelling out. Assignment answers the question of who should deal with this thread. Collision detection answers the question of who is dealing with it right now. Those are different questions, and only the second one prevents the client from getting two replies.
The gap shows up most on threads that arrive before the rules run, on threads that get reassigned mid-conversation, and on the account everybody feels ownership over. A large client writes in, three people who all work with that client see it, and each of them thinks their answer is the one that is needed. Assignment does not stop that. A live typing indicator does.
What good collision handling looks like in practice
If you are evaluating tools, these are the behaviours worth testing during a trial rather than reading about.
- The signal fires when someone starts typing, not just when they open the thread.
- It is visible without hovering or clicking. It should be in your peripheral vision from the list view.
- It clears itself. Indicators that get stuck because someone closed a laptop lid teach people to ignore them.
- It works across devices, so a colleague drafting on a phone is visible to someone on a desktop.
- It survives reassignment, so handing a thread over does not leave two people thinking they own it.
One more that gets missed: what happens on a thread where the reply is not the whole story. If your team's answer to a client depends on what somebody promised them last month, the collision you want to avoid is not just two replies. It is two different answers. Tools that keep a record of commitments and open questions per client, which is the job Sektra is built for, mean the second person to arrive at a thread can see what the first one would have said.
A short rollout that actually sticks
Turning the feature on is not the same as changing the behaviour. Four steps that take about a week.
- Count the problem first. Search sent mail for the last month and find threads with two replies from your side within ten minutes. Most teams are surprised by the number, and having it makes the case for you.
- Turn detection on for everyone at once, not as a pilot. A partial rollout means half the team is invisible to the other half, which is worse than nothing.
- Agree one rule out loud: if you see the indicator, you do not reply. You comment internally instead. The rule matters more than the feature.
- Recount after two weeks. If the number has not moved, the signal is firing too late, and that is a vendor question rather than a team question.
The reason this is worth a week of attention is not the embarrassment. It is that a client who receives two different answers from your team stops trusting the first answer they get from you, and that cost keeps accruing long after the thread is closed.
