Somewhere in your organisation there is a user manual nobody has opened since the week it arrived. It is thick, thorough and professionally formatted, and it answers almost no question a working person actually asks. It was written to prove that everything was documented — which is not the same as helping anyone do anything.
Documentation fails when it is written for auditors instead of operators. An auditor asks whether every feature is described. An operator asks something entirely different: it is Tuesday morning, this file has just landed on me, what exactly do I do next?
Software built to streamline how a company works deserves documentation held to the same standard. So we ship two things with every module we deliver — a step-by-step operating procedure and a decision flowchart — written for the second reader, not the first.
The screen-by-screen trap
Most software documentation is organised the way the software is built — screen by screen, field by field. This page contains these buttons; this menu opens these options; this report offers these filters. It reads like an inventory, because that is what it is.
But nobody's job is a screen. A person's job is a situation: a requisition to raise, a candidate to move forward, an approval to give or refuse, a site update to file. Inventory-style documentation leaves the reader to translate between the situation they are in and the screens it might involve, and most people, reasonably, refuse the translation work. They ask a colleague instead, and the manual goes back on the shelf for good.
That is how organisations end up running on oral tradition — process knowledge held in a handful of heads, retold with small variations, until the actual procedure is whatever the most confident person in the room remembers.
Write for the person holding the file
Useful documentation starts from the other end: not what the system contains, but what a person should do. For every module we ship, the standard operating procedure answers three questions, in order — who acts, what they check, and where it goes next.
So the SOP for approving a manpower requisition does not describe the requisition screen. It walks the approver through the act: open the file, verify these details against these rules, then approve, reject or return — and here is what happens after each choice, and who is informed automatically.
Written this way, a procedure is short. It fits in a page or two, because it carries only what that role needs for that task — which is precisely why it gets read, and why it keeps being read after the trainer has left.
There is a side benefit for management, too. Writing down who acts and what they check forces vagueness into the open — if nobody can say what the approver is meant to verify, the gap was in the process, not the documentation, and it is far cheaper to close it on paper than to discover it in an audit.
Flowcharts carry the decisions
Steps are only half of a process. The other half is branches: if the value crosses a limit it goes up a level, if documents are incomplete it goes back, if the candidate declines the offer the role returns to sourcing. Prose handles branches badly — every fork doubles the sentences and buries the shape of the process.
So every module also gets a decision flowchart, with the branches drawn as branches. One page shows every route a file can take, every point where a person decides, and every automatic step in between — the reminders, the notifications, the records. When a case turns unusual, nobody reconstructs the logic from memory. They follow the line.
The flowchart is also where policy stops being folklore. If the chart shows that a rejected requisition returns to the requester with reasons, then that is the process — visibly, for everyone, including the person who joined on Monday.
When a new joiner asks how something works, the answer is a page, not a person.
Per module, because that is the size of a real question
A single master document covering the whole system fails for the same reason the screen-by-screen manual does: it serves the filing cabinet, not the reader. Nobody sits down to learn a system. They sit down to do a task.
So we write SOPs and flowcharts per module — one for raising requisitions, one for screening, one for offers, one for joining — matching the shape of the documentation to the shape of the work. A person opens the one page that answers their situation and ignores the rest with a clear conscience.
The module boundaries come from the process map, not from the software's menu. If your organisation treats screening and interviewing as one motion, the documentation should too — the pages follow the way your people divide the work, because that is how they will search for answers.
Per module also means maintainable. When one process changes, one document changes with it and the others stay true. Documentation that is easy to update stays accurate, and documentation that stays accurate keeps being trusted — which is the entire game.
Handover is when documentation earns its keep
We treat these pages as part of handing a system over properly, not as an appendix. They arrive alongside structured test scripts with role-wise accounts and kickoff training, and you approve all of it before go-live — the documents as much as the software, because your team will run both. If a procedure reads as unclear during testing, that is a defect, and we fix it like one.
The effect shows up in quiet ways. Fewer questions travelling upward to the two people who know everything. Fewer processes living in one indispensable head. New joiners who are productive in their first week, because the answer to the question they would have asked is a page they can hold — and training that walks through pages people keep, instead of slides people forget.
That is the standard we build to: the busywork runs itself, your people stay in control of the decisions, and the knowledge of how everything works belongs to the organisation — written down, drawn out, and read.