Why two people answer the same email, and five fixes
A teardown of a duplicate-reply incident in a shared inbox: the five root causes behind it, fixes ranked by effort, and how to apologize when it still happens.

On this page(6 sections)
- The incident
- Root causes
- 1. No claim signal
- 2. Stale view
- 3. Unclear rota versus specialist rules
- 4. Mobile glance without action
- 5. Reply-all from a cc'd teammate (a related variant)
- Five fixes, ranked by effort
- Fix 1: Write a precedence rule
- Fix 2: Claim before you write
- Fix 3: Look at the thread before sending
- Fix 4: Route specialist topics at triage
- Fix 5: Pull cc'd conversations into the shared inbox
- When it happens anyway: how to apologize
- Running a lightweight review
- Bottom line
The customer asked one question and got two answers, eleven minutes apart, from two different people, and the answers didn't agree. Nobody on the team did anything unreasonable. That's what makes duplicate replies worth taking apart: they're almost always a process failure, not a people failure.
Below is a composite incident, typical of what small teams run into, followed by the root causes and five fixes ranked from cheapest to most involved.
The incident
A six-person SaaS team runs support@ as a shared inbox. On a Tuesday morning, a customer writes:
Hi, we were charged twice this month. Can you refund one of them?
Here's what happened next:
- 9:02 The email arrives.
- 9:05 Dana, on the support rota, opens it on her phone while getting coffee. She plans to reply when she's at her desk.
- 9:09 Marcus, who handles billing, sees it in the shared inbox. It looks untouched. He checks the payment system, confirms the double charge, and starts writing.
- 9:14 Dana sits down, opens the thread on her laptop, and writes: "Sorry about that! I've asked our billing team to look into it, and we'll get back to you within a day."
- 9:16 Dana sends.
- 9:25 Marcus sends: "I've refunded the duplicate charge. You'll see it in 5–10 business days."
The customer now has two replies. One says "we'll look into it," the other says "done." They reply, slightly confused, asking which is right. Dana and Marcus discover the overlap in chat. Nobody's hurt, but the team looks disorganized, and two people spent time on one email.
Root causes
Walk the timeline and five distinct causes show up. Most incidents involve at least two.
1. No claim signal
Dana decided at 9:05 that the email was hers. That decision lived only in her head. When Marcus looked at 9:09, nothing in the inbox said "Dana is on this." From his side, the thread was unclaimed.
2. Stale view
Marcus started writing at 9:09. Dana sent at 9:16. If Marcus's screen didn't show Dana's reply until he refreshed, or he simply didn't look back at the thread before sending at 9:25, he had no way to know.
3. Unclear rota versus specialist rules
Dana was on rota, so new threads were hers. Marcus handles billing, so billing threads felt like his. Both were following a rule; the rules just conflicted. Nobody had written down which wins.
4. Mobile glance without action
Opening an email on a phone and intending to reply later is completely normal. But in a shared inbox, opening it might mark it read for everyone, making it look handled, or it might do nothing visible at all, making it look untouched. Either way, intent wasn't communicated.
5. Reply-all from a cc'd teammate (a related variant)
This incident didn't involve it, but it's the other common source of duplicates: a customer cc's two people at your company, and each replies from their own inbox. The shared inbox never sees one of the replies.
Five fixes, ranked by effort
| Fix | Effort | Addresses |
|---|---|---|
| 1. Write a precedence rule | Minutes | Rota vs specialist conflict |
| 2. Claim before you write | Minutes to agree, days to habit | No claim signal, mobile glance |
| 3. Look at the thread before sending | A habit | Stale view |
| 4. Route specialist topics at triage | An hour to set up | Rota vs specialist conflict |
| 5. Pull cc'd conversations into the shared inbox | Ongoing coaching | Reply-all variant |
Fix 1: Write a precedence rule
Decide which rule wins when rota and specialty overlap. A common choice: the rota person owns every new thread and pulls in the specialist, rather than the specialist grabbing billing emails directly. Or the reverse: specialist topics go straight to the specialist, and the rota person leaves them alone. Either works. What doesn't work is both.
Fix 2: Claim before you write
Make "this is mine" visible before you start writing, not when you send. Depending on your tools, that might be a label with your name, a quick note in the team channel with the thread link, or a feature built for it. On mobile, the rule is: if you open it and intend to handle it, claim it right then, or leave it unclaimed for someone else.
Fix 3: Look at the thread before sending
A two-second habit: before you press send on a shared-inbox reply, scroll to the bottom of the thread and check that nothing new has arrived from a teammate or the customer. This alone would have caught the incident above.
Fix 4: Route specialist topics at triage
If billing emails go to Marcus, have the triager label them Billing as they arrive, so they leave the general queue. Auto-label rules can do some of this based on keywords or senders, with the triager catching the rest.
Fix 5: Pull cc'd conversations into the shared inbox
When a customer emails people directly, the first person to reply should add or move the conversation into the shared address, so everyone sees one thread. Coaching beats rules here: explain why, and the habit spreads.
When it happens anyway: how to apologize
Even with good process, duplicates will occasionally slip through. A short, clear correction is better than silence or a long explanation. Have the person whose reply was more accurate send it:
Hi [name],
Apologies for the two replies earlier — two of us picked this up at the same time.
To confirm: the duplicate charge has been refunded. It can take a few business
days to show on your statement, depending on your bank.
I'll be your contact on this from here. Let me know if anything else looks off.
Marcus
Three elements matter: acknowledge it briefly, state the correct answer clearly, and name one person as the contact from here on. Don't blame a colleague or the tools.
Running a lightweight review
After a duplicate, a five-minute conversation is enough. Ask:
- What did each person see, and when?
- Which rule did each person think they were following?
- Which of the five causes was involved?
- What one change would have prevented it?
Write the change into your ownership rules. If the same cause shows up twice, move up the effort ladder.
Bottom line
- Duplicate replies are process failures: invisible claims, stale views and conflicting rules.
- The cheapest fixes are a precedence rule and claiming before writing.
- Checking the thread right before sending catches most remaining overlaps.
- When it happens, the more accurate replier sends one brief correction and becomes the single contact.
- Review each incident in five minutes and update the rules, not the people.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.

