Your day to day
Closing a file properly
Finishing the work and closing the file are two different things, and hardly anyone does the second.
Almost every file ends without being closed. The work finishes, people move on, and the file stays open forever — until someone counts what is outstanding and gets a figure that means nothing.
What not closing costs
| Consequence | How it shows |
|---|---|
| Counts stop being useful | "We have eighty open" and forty are done |
| Reminders keep going out | To third parties who already delivered, and you look bad |
| The same things get reviewed weekly | Someone looks, sees it is fine, and does not close it either |
| And what is genuinely stuck hides | Among those that only look stuck |
Important
The fourth does the real damage and is hardest to see. If forty of eighty open files are finished, the five blocked for months do not stand out — they are lost in the noise. **Closing is not tidiness: it is what makes the real problem visible.**
What to check before closing
- 1
That no requests remain open
That is what keeps sending reminders after the work is done.
- 2
That what must be kept is there
Whatever you will be asked for about this matter in future.
- 3
That what was promised is done or noted
An outstanding commitment in a closed file disappears.
- 4
And that any exceptions are closed
An open exception in a closed file is the worst combination.
Watch out
The case worth handling separately: the file that will **not** be completed. It is not closed like a finished one — it is closed saying why. "Closed incomplete: the supplier never supplied insurance and we decided not to work with them" informs; closing it silently leaves whoever looks in two years thinking you forgot.
When it should stay open
Outside those three, an open file is not caution: it is noise that will stop someone seeing what matters.
Worth knowing
Closing deletes nothing: the file stays complete, searchable and with its history. All that changes is that it stops counting among what is in progress and stops generating alerts.
›Can it be reopened?
Yes, and that is normal if something new comes up on that matter.
›What if a minor document is missing?
Decide: either request it and keep it open, or close it noting it was not requested.
›Who should close it?
Whoever owned it. If nobody owned it, that was the underlying problem.
A real case
The situation
A team counts eighty open files and cannot tell which matter.
What you do
- Closes the finished ones and notes the reason on those never completed
What you get
Twelve genuinely open remain, and the five stuck for months are visible at once.
The situation
A file is treated as closed and two months later a document is missing.
What you do
- Checks what is outstanding before closing
- Records the reason for closing
- Notes whether anything is deliberately left open
What you get
Closing means the same to the whole team and can be explained months later.
The situation
It is closed and reminders keep going out.
What you do
- Stops the open processes on closing
What you get
Nobody outside receives requests about something closed.
The situation
Nobody knows why a file was closed incomplete.
What you do
- Notes the reason in the closure itself
What you get
The decision is explicable.
The situation
The file is reopened and the earlier work is lost.
What you do
- Reopens instead of creating a new one
What you get
The history is preserved.
The situation
Metrics count dead files as open.
What you do
- Closes what will not progress
What you get
The numbers say something again.
This article answers
- when to close a file
- what to check before closing
- finished files still open
- close or leave open