---
id: KB-CL-017
url: https://app.codecontract.io/help/collaboration/two-people-working-on-the-same-file
idioma: en
categoria: colaboracion
subcategoria: externos
audiencia: usuario
nivel: basico
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-TD-014, KB-TD-006]
citadoPor: [KB-CL-018]
---

# Two people working on the same file

_When two colleagues chase the same supplier, the supplier looks bad and you lose the time._

**Responde a:** two people request the same thing from a supplier · colleagues duplicating work · who owns this file · avoiding duplicate requests in the team

It happens in any team of more than two: two colleagues work the same matter without knowing, and the third party — the supplier, the client — gets two similar requests, answers one, and is left with the impression that you do not talk to each other in there.

## How it shows up

| Symptom | What is happening |
| --- | --- |
| The supplier says "I already sent it to your colleague" | Two requests, one answer, and the other still open |
| Two reminders arrive about the same thing | Nobody closed the request on receipt |
| Two people approve the same thing differently | It was not clear who decided |
| Someone redoes work already done | The result existed, but somewhere else |

> [!IMPORTANT]
> The first row is the commonest and has an invisible consequence: **the supplier is right and you are still waiting**. They sent what was asked, to whoever asked; what failed is that the delivery did not close the other request. And when you chase, the relationship suffers over something they did not do wrong.

## What prevents it, and it is not a meeting

1. **One owner per file, by name** — Others help, one answers. Without that, everything else is a patch.
2. **Request from the file, not from email** — It is what makes visible that a request is already open on that.
3. **Close the request on receipt, not at day's end** — An open request with the document already in is what fires the second reminder.
4. **And look at the file before writing** — Ten seconds that prevent the whole conversation.

> [!WARNING]
> What annoys the third party most is not receiving two requests: it is receiving the second **after having answered the first**. To them it means you did not read them. If you spot that it happened, say so before they do — one line acknowledging it costs less than the distrust it otherwise leaves.

## When two people must work at once

**En corto**

- Split by parts of the file, not by shifts: one handles documentation, the other the technical side.
- Have communications always go out from the same place, whoever writes them.
- And make clear who decides if something must be decided.

The second solves nearly everything: if the third party always hears from the same sender and replies to the same place, how many of you are behind it does not matter to them.

> [!NOTE]
> The log says who requested what and when, so these situations are clarified by looking rather than reconstructing from memory. What it does not fix is the impression the third party took away, which is why heading them off early matters.

**What if two of us handle it deliberately?**

Then one is the owner and the other supports: two owners is none.

**Do two requests count as two actions?**

Yes: every send counts, even the same document to the same person.

**Can I see whether a request is already open?**

Yes, in the file itself: that is exactly what prevents the duplicate.

## Ejemplos

**A supplier receives two requests for the same certificate in one week.**

- They assign an owner per file and close requests on receipt

→ Crossed reminders stop and the supplier stops replying "I already sent it".

**Two people work the same file and both write to the supplier on the same Tuesday.**

- Assigns an owner to the file
- Checks who handles it before writing
- Leaves notes in the file rather than in each inbox

→ The supplier receives one message and the team does not duplicate work.

**One approves a document and the other rejects it the same day.**

- Writes the criteria into the template

→ The decision is the same whoever takes it.

**Each keeps their notes in their own inbox.**

- Records notes in the file

→ The context is shared.

**One goes on holiday and the other does not know where things stood.**

- Checks the file's history

→ The handover does not depend on a conversation.

**Both chase the supplier with different deadlines.**

- Sets the deadline in the file itself

→ The supplier receives one date.

**Nobody knows who did what in the file.**

- Checks the log with author and date

→ Every action has an owner.

**The file moves on and the other finds out late.**

- Sets change notifications for both

→ Both work on the same thing.