Glass-roofed hall with display cases on several levels
Glass-roofed hall with display cases on several levels

Implementation

Silvercrest AI · Insights

Document Filing Automation: Intake, Versions and Exceptions

Improve document filing with agreed categories, identifiers, version states and an exception queue. Measure the time to find and confirm the right document.

Table of contents

Share

Share

A contract sits in twenty versions across ten folders. Three are called final, two carry a date, one has the name of whoever touched it last. Whoever needs it searches first for the file and then for the certainty, and the second search takes longer.

A contract sits in twenty versions across ten folders. Three are called final, two carry a date, one has the name of whoever touched it last. Whoever needs it searches first for the file and then for the certainty, and the second search takes longer.

The cost has two parts: finding the file and confirming that it is the right one. A useful filing project measures both. Faster search is not enough if somebody still has to ask a colleague which version can be trusted.

Why is this time easy to overlook?

It often sits between named processes. Checking a version may be recorded as part of preparing a report, rather than as a separate activity. That makes recurring friction harder to see.

For an illustrative calculation, ten people each spending six minutes a day checking versions adds up to five hours over a five-day week. Measure a sample before treating that figure as your own opportunity.

Where does the damage actually show?

Wrong-version decisions, duplicate work and delayed handovers are all possible consequences. Record them separately: a search-time saving and an avoided operational error are different benefits.

Why is this not a discipline problem?

Because the disagreements are reasonable. A building permit belongs under building permits for one person and under authority correspondence for another, and neither is wrong.

Individual judgement needs a shared framework. Agree a small set of document types, identifiers and version states, then make exceptions visible. The aim is not to remove judgement but to stop every person reinventing the filing rules.

Is the intake or the archive the real problem?

Both can matter. New intake benefits from agreed rules; an existing archive may contain duplicates, missing references and obsolete versions. Stabilise the intake first so an archive clean-up does not immediately become outdated.

Frequency makes small delays significant. Count searches, average time and the people involved. Keep version errors and the cost of rework visible rather than hiding everything inside one estimated saving.

What actually fixes a filing system?

Combine a repeatable intake rule with a visible exception queue and a named owner. A one-off clean-up is useful, but somebody still needs to maintain the rules and resolve unfamiliar cases.

Each document receives a proposed type, location and name based on its content and identifiers. Validate that proposal against the source. If classification is ambiguous, the system should ask rather than confidently file it in the wrong place.

What condition has to come with the rule?

That when the assignment is uncertain, nothing is filed and nothing is renamed. The case goes to a person together with the reason it stopped.

Without that condition the rule produces a new disorder that looks like order, which is worse than the old one because it is trusted.

What happens to the existing archive?

Test the rules on a copy or a read-only sample of the archive first. Show the proposed changes for approval, preserve the originals and define how a mistaken move or rename can be reversed.

The result should distinguish already-correct files, approved changes and unresolved cases. That last group shows where the taxonomy or available information needs more work.

How do you know it held?

Compare time to find and confirm a document before and after the change. Sample filing accuracy, duplicate rates and unresolved cases as well. Fewer questions can be encouraging, but silence alone is not evidence that the system is correct.

A useful outcome is both speed and confidence: people can locate the current version, understand its status and see what still needs review.

See a property data-room workflow