---
id: KB-IC-005
url: https://app.codecontract.io/help/reports-and-quality/when-a-supplier-keeps-failing
idioma: en
categoria: informes-y-calidad
subcategoria: calidad
audiencia: usuario
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-IC-002, KB-IC-004]
citadoPor: [KB-IC-007, KB-IC-012, KB-CR-014, KB-IC-013]
---

# When a supplier keeps failing

_From an isolated incident to a decision: when there is a pattern and what to do with it._

**Responde a:** supplier repeatedly failing · supplier evaluation incidents · when to stop working with a supplier · supplier incident history

One failure is a failure. Three from the same supplier in six months are not: they are a pattern, and the difference between seeing it and not is having the history together rather than spread across three people's memories.

## How a pattern shows

| Signal | What it usually means |
| --- | --- |
| Always late with the same item | They do not have it, and get it when pushed |
| Fails when their contact person changes | The problem is their organisation, not their willingness |
| Delivers expired documentation | They do not check it before sending |
| Fails only on one site or with one client | It is a local problem, not the supplier's |

> [!IMPORTANT]
> The last row is the most overlooked. Before concluding a supplier is bad, check whether they fail with everyone or only in one place: if it is one, the problem may be how they are being asked from there.

## What to do with the pattern

1. **Show it to them** — With specific dates, not "you are always late". Most correct course once they see the list.
2. **Adjust what you ask for** — If the same document always fails, check whether you are asking for it well.
3. **Decide, and write it down** — Continue, continue with conditions, or stop. All three are valid; not deciding is not.

> [!WARNING]
> Be careful scoring suppliers with a number and no context. A supplier with three incidents in three hundred deliveries is not worse than one with one in four, and a badly built score ends up punishing whoever does most work for you.

> [!NOTE]
> When the decision is to stop working with someone, the dated history is what sustains it if that company objects. Without it, it is your impression against theirs.

**Should I show the supplier the history?**

It is usually the most effective step: most do not know there is a pattern.

**How many incidents make a pattern?**

It depends on volume. What matters is the proportion, not the count.

**What if they are indispensable?**

Then the decision is to continue with conditions, and those are worth writing down.

## Ejemplos

**A company is about to drop a supplier over repeated incidents.**

- Checks the history: all of them come from one site
- Reviews how requests are made from there

→ The problem was that site's process, and the supplier stops failing without changing supplier.

**A supplier fails for the third time and the conversation happens without data.**

- Checks their incident history before meeting
- Brings the dates and the impact of each
- Agrees a plan with a review date

→ The conversation stops being an impression and the supplier knows what is measured.

**Suppliers are switched without knowing whether the new one will be better.**

- Compares both histories

→ The decision is taken with data.

**Each department has its own view of how that supplier is doing.**

- Checks the same source for all

→ The company speaks with one voice.

**A plan is agreed and nobody reviews it.**

- Sets the review date when agreeing it

→ The plan is met, or you know it is not.

**The supplier improves and nobody acknowledges it.**

- Checks the period's trend

→ The relationship matches what is happening now.