---
id: KB-TL-017
url: https://app.codecontract.io/help/trackline/how-long-a-file-takes-to-close
idioma: en
categoria: trackline
subcategoria: seguimiento
audiencia: usuario
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-TL-008, KB-IC-006]
citadoPor: [KB-TL-012]
---

# How long a file takes to close

_The figure that warns earlier than any other, and how to read it without fooling yourself._

**Responde a:** how long we take to complete a process · measuring file cycle time · why closing takes so long · processing time indicator

The percentage of files up to date is the figure everyone watches, and it warns worst: it holds up nicely until it suddenly drops. Average time to close moves weeks earlier, because it picks up what is jamming right now.

## The three ways to read it

| Measure | What it says | When it misleads |
| --- | --- | --- |
| Mean | General behaviour | Four endless cases inflate it and everything looks bad |
| Median | How the typical case goes | It hides a tail of very old cases |
| Oldest still open | Where the specific problem is | It never misleads, and it is the least watched |

> [!IMPORTANT]
> Look at all three, especially the third. If the mean worsens but the median does not move, you do not have a process problem: you have four specific jammed cases, and that is fixed with four conversations, not a redesign.

## Where the time actually goes

1. **Waiting for someone outside to supply** — Almost always the longest leg, and the one automatic chasing shortens most.
2. **Waiting for someone inside to review** — The second, and the most uncomfortable to admit.
3. **In a step nobody knows is theirs** — The classic in multi-party processes.
4. **And in formal closure** — Files finished in practice that nobody marks as closed.

> [!WARNING]
> The fourth pollutes every figure and is not a real problem: closing them when they finish already delivers half the apparent improvement. Rule it out before drawing conclusions about the process.

## What to do with the figure

**En corto**

- Compare it with itself, month to month, not with anyone outside.
- Split it by file type: an onboarding does not take as long as a renewal.
- And look at the leg, not the total: the total does not say where to act.

Once split by legs, the conversation changes: it stops being "we're slow" and becomes "eleven days waiting for the supplier and four to review", which are two different problems with two different owners.

> [!NOTE]
> If time falls but approved exceptions rise, you have not improved: you have started letting things through. The two figures are read together or not at all.

**How often should it be checked?**

Monthly. Weekly only while correcting something.

**What if we have few files?**

Look at the oldest one open; a mean over few cases says nothing.

**Is it useful for targets?**

Yes, but per leg. A target on the total is met by whoever closes early, not whoever works better.

## Ejemplos

**A team sees its average time rise and considers redesigning the process.**

- Checks the median, which has not moved, and the oldest open file
- Resolves four jammed cases

→ The average returns to normal without touching the process, which was not the problem.

**Average time rises and nobody knows why.**

- Checks whether the rise comes from one phase

→ The stretch that lengthened is tackled.

**The average hides a few very long cases.**

- Also looks at the extremes

→ You see the real problem rather than the mean.

**The figure is compared across months without context.**

- Accounts for campaigns and holidays

→ The comparison is honest.

**Time is counted from when someone opens it by hand.**

- Counts from when the request was sent

→ The figure reflects what the other side waits.

**It is measured and nothing is done with the figure.**

- Sets a target and reviews monthly

→ The indicator supports a decision.