Document projects are specified around storage and judged on retrieval. The test that matters is whether somebody can find the right version eighteen months later without asking the person who filed it.
This guide covers what to capture, which few properties people actually search on, how to settle retention with somebody who can decide, and why doing one document type properly beats surveying all of them.
Key takeaways
- Retrieval is the test: Ask three colleagues to find an eighteen-month-old document and time them before specifying anything.
- Three fields enforced beat fifteen specified: Metadata nobody fills in is worse than a short list that is mandatory at entry.
- Retention is a policy gap: Most organisations keep everything because nobody would sign the deletion decision, and no system fixes that.
- Do one document type properly: One type handled end to end teaches more than an inventory of every type you hold.
Start with the business outcome
Success is somebody finding the right document a year later without asking the person who filed it. Write down which document type you are starting with, because retention and access rules differ enough between types that doing all of them at once stalls.
Ask three colleagues to retrieve a specific document from eighteen months ago and time them. What they searched on is the metadata the system needs, and what they never thought of is what you can safely leave out.
Four areas to define before choosing features
1. Capture
Work out where the document enters from, in what format, and how much of its description is typed by hand today. If capture depends on somebody remembering to fill in four fields, the search problem you are trying to solve starts here.
2. Classify
Choose the handful of properties someone will actually search on later and decide who supplies them. Teams routinely specify fifteen metadata fields and find three of them populated, which is worse than specifying three and enforcing them.
3. Review
Name who must read the document before it counts, what they are checking, and how a rejection is communicated. A review step with no stated criteria becomes a queue that one person works through at whatever pace their week allows.
4. Retain
Set out how long it must be kept, what triggers deletion, and who may override that. Most organisations keep everything forever because nobody would sign the deletion decision, and a system cannot resolve a policy gap on their behalf.
Decide what to measure
Measure cycle time, backlog, rework, exception rate, and outcome quality by workflow. Activity volume alone can reward busy systems instead of better ones.
Manage the most likely risks
| Decision area | Risk to make visible | Practical safeguard |
|---|---|---|
| Capture | Capture depends on somebody remembering | Reduce the fields to the handful people will actually fill in and enforce those. |
| Classify | Classification is specified and then ignored | Pick the properties people search on and make them mandatory at the point of entry. |
| Review | Review has no stated criteria | Say what the reviewer is checking and how a rejection is communicated. |
| Retain | Nothing is ever deleted | Agree the retention period per type and who may override it, with a named approver. |
Build a roadmap around evidence
1. Test retrieval today
Ask three people to find a specific old document and note where they looked first.
2. Settle retention with someone who can decide
Get a written answer on how long one type is kept and what triggers deletion.
3. Run one type through the new states
Move a single document type into a structured folder with classification and a review step.
4. Measure retrieval again
Repeat the original test at the end of the month before extending to a second type.
For how document handling connects to the wider staff experience, see Why Back-Office User Experience Matters to Customers.
Plan adoption and operating ownership
The people who file documents and the people who search for them are usually different, and only the second group feels the benefit. Show the filing team the retrieval test results so the extra fields have a visible purpose. Decide who owns the classification scheme when a new document type appears, because without that the scheme drifts within a year and the search problem returns.
Make the data and system boundaries explicit
List the records document workflow software needs to read, create, update, and preserve. For each record, identify its source of truth, owner, freshness requirement, correction path, retention need, and allowed roles. Connect the list to capture, classify, review, and retain so data work remains tied to product behavior.
The result should help the business define document states, metadata, access, review, approval, retention, and search while retaining control of the information the product depends on. It also gives potential partners a fairer basis for estimating integration, migration, backend, and operating work.
A 30-day validation plan: Document workflow
Days 1 to 5: try to find three documents. Ask three colleagues to retrieve a specific document from eighteen months ago and time them. Note where they looked first and what they searched on. The properties they tried are the metadata the system needs, and the ones they never thought of are the fields you can safely drop. Do it without warning them, because a retrieval test that people prepare for measures their preparation rather than the filing.
Days 6 to 15: settle retention with someone who can decide. Take one document type and get a written answer on how long it must be kept and what triggers deletion. If nobody will give that answer, the honest finding is that retention is a policy gap rather than a software requirement, and no system will resolve it for you. Ask what would happen if the document were produced late to a regulator, since that answer tends to settle the retention argument quickly.
Days 16 to 30: run one type through the new states. Move a single document type into a structured folder with agreed classification and a review step, using existing tools. Measure retrieval again at the end of the month. One type handled properly teaches more about the real workflow than a full inventory of every type you hold. Pick the type that is retrieved most often rather than the one with the largest volume, as frequency is what makes the saving recur.
A practical worksheet: Document workflow
Document workflow projects fail on retrieval, not on storage. Pick one document type that matters and complete a row for each stage of its life.
| Decision area | What to record |
|---|---|
| Capture | Where the document enters from, in what format, and how much of its description is typed by hand today |
| Classify | The handful of properties someone will search on later, and who is required to supply them |
| Review | Who must read it before it counts, what they are checking, and how a rejection is communicated |
| Retain | How long it must be kept, what triggers deletion, and who is allowed to override that |
| Measurement | Time to find a specific document a year later, tested with a real request rather than estimated |
Test the retention rule against a real legal or audit request before building. Teams usually find they are keeping everything forever because nobody was willing to make the deletion decision, and that is a policy problem a system cannot solve.
Related guides
- A related mistake worth avoiding is described in Admin Dashboard Development: Features, Architecture, and Cost Drivers.
- If that is the next question, read Operational Dashboard: KPIs, Examples, and Design.
If Document Workflow: Steps, Controls, and Automation exposes manual steps worth removing, Discuss Your Operations Platform.
Ali Boran Gazel