---
id: KB-CC-015
url: https://app.codecontract.io/help/contacts-and-channels/asking-several-people-for-the-same-thing
idioma: en
categoria: contactos-canales
audiencia: usuario
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-CC-014, KB-CF-012, KB-CC-005, KB-CC-008]
citadoPor: [KB-CC-018]
---

# Asking several people for the same thing

_Sending it to three just in case feels safer and usually means none of them replies._

**Responde a:** send the request to several people at the company · copying in several contacts · nobody replies although i sent it to three · who to address a document request to

When something is urgent, the reflex is to send it to every contact you have at that company. It is understandable and counterproductive: when a request reaches three people without saying whose it is, each assumes another will answer. It is called diffusion of responsibility and it works the same everywhere.

## What happens depending on who you send it to

| How it is sent | What usually happens |
| --- | --- |
| To one named person | They reply or say who should |
| To three, without saying whose it is | None replies, and all three think it is covered |
| To a generic mailbox | Someone opens it, decides it is not theirs, and it dies |
| To one person, with another copied | It works: there is an owner and a witness |

> [!IMPORTANT]
> The fourth row is barely used and solves the real case. If you want more than one person aware, make one the recipient and copy the other: the request still has an owner, and the second person knows it exists without feeling responsible for replying.

## When sending to several is right

**En corto**

- When each must supply something different: then it is not one request, it is several.
- When the deadline is very short and you prefer redundancy to order.
- And when you do not know who handles it: there the first request is "who handles this?", not the document.

The first case is the commonest in practice and is better solved by splitting: one request per person, each with their own. That way you can see who is missing, without the ambiguity of a shared list.

> [!WARNING]
> On cost, so it does not weigh on the decision: **a request counts as one action even when it goes to several contacts**, and a bulk send counts as one, not one per recipient. Verified in the platform's own action catalogue. So the reason not to send it to three is not spend: it is that it works worse.

## When two contacts really are needed

1. **Name the one who answers** — In the text itself: "Marta, can you send it over?". It costs five words.
2. **Make clear what the other is there for** — "Copying you so you know" stops both from waiting.
3. **And if the owner changes, change it here too** — Chasing someone who no longer handles it is the commonest cause of never-ending requests.

> [!NOTE]
> When the answer arrives, it lands in the file whoever sends it. That a different person supplies it does not break anything — what helps is that it stayed clear who was on the hook.

**What if the right person is on leave?**

Send to their cover by name, not to the whole team.

**Can I see which of the three opened it?**

Yes, the send status shows it, and it usually explains the silence.

**Should I copy their manager?**

As a last resort it works; as a habit, it burns the resource.

## Ejemplos

**A company sends the same request to three contacts at a supplier and nobody replies.**

- Resends to one named person, copying the other

→ Gets the document within two days, without changing a word of the request.

**The same thing is asked of three people and all three reply.**

- Addresses the request to one and copies the rest

→ You get one answer rather than three versions.

**Several are asked and none replies.**

- Names an owner in the request

→ Somebody is on the hook.

**Two people upload the same document.**

- Makes clear who provides what

→ Duplicated work is avoided.

**Each one sends a different version.**

- Asks them to coordinate before sending

→ One version arrives rather than a conflict.

**Nobody knows who has already replied.**

- Checks the status per recipient

→ Only those outstanding are chased.