Guides
Part of Sop templates: what belongs in each section
How to judge SOP software on version history, findability and a seven step trial
Judge SOP software by version history, permissions, findability and print use, with a seven step trial script, export test and when a shared folder is enough.
Procedure tools are demonstrated on the writing. Writing is the part that was never hard. What decides whether a tool is worth its cost is year two. Can you still produce the version someone followed last March? Does a correction take two minutes or a meeting? Can anyone find the document while standing at the machine?
This page is a checklist for judging one, not a list of products. What a procedure should contain is in the SOP templates overview.
What to take away
- Judge a tool on retrieval and correction, not on its editor.
- Run the same trial script on every candidate, and make the last step an export.
- If the people doing the work cannot fix a wrong step themselves, the documents will be wrong.
The five jobs, and what to test
The five jobs
| Job | What good looks like | Trial step |
|---|---|---|
| Author | A fixed house structure that authors fill rather than reinvent | Create a procedure and try to remove a mandatory section |
| Find | A search that hits words in the body, from a phone, in one attempt | Search a word that appears in only one document |
| Follow | A readable step view at arm's length, no pinching, no side-scrolling | Open one on the oldest phone your team uses |
| Correct | A small fix by the person doing the work, logged, without an approval queue | Change one step as a non-admin user |
| Prove | The exact version in force on a past date, retrievable after two revisions | Ask it what was live three revisions ago |
The fifth row is the one vendors are least ready for and the one that matters most in an audit or after an incident.
Five Jobs and What to Test
Job
- Author
- Fixed house structure
- Find
- Body-word search, phone, one try
- Follow
- Readable at arm's length
- Correct
- Small logged fix, no queue
- Prove
- Past-date version retrievable
What good looks like
- Author
- Remove mandatory section
- Find
- Search unique word
- Follow
- Open on oldest phone
- Correct
- Edit as non-admin
- Prove
- Ask three revisions ago
Trial step
- Author
- Find
- Follow
- Correct
- Prove
Version history you can actually use
Version history you can use
- Every version kept, with who approved it and when it took effect.
- A readable difference between two versions that says which step changed, not that the document changed.
- The version in force on a given date, retrievable by date rather than by counting backwards.
- An export of the whole history, because a version record inside a tool you have left is not a record.
Ask specifically what happens to history when a document is renamed or moved. In several systems it starts again, which is discovered at the worst possible moment.
Version History Must-Haves
- Every version kept with approver and effective date
- Readable difference naming which step changed
- Version in force on a date, retrievable by date
- Export of the whole history outside the tool
- Check what happens to history on rename or move
Access and permissions
Three groups need different things and most tools collapse two of them.
Three Permission Groups
Group
- Readers
- Open without login where safe
- Doers
- Propose or make small fixes
- Owners
- Approval, retirement, change log
Needs
- Readers
- Wall-mounted read needs no password
- Doers
- Tools offer full edit or nothing
- Owners
- Retirement must remove from view
Watch for
- Readers
- Doers
- Owners
Readers need to open documents without a login where that is safe, or with a login that survives a shared device. Requiring a personal password to read a wall-mounted procedure means people photograph it instead, and the photograph is the version they will use next year.
Doers need to propose or make small corrections. This is the permission most tools handle worst, offering either full edit rights or nothing.
Owners need approval, retirement, and the change log. Check that retirement actually removes a document from where staff look, rather than only marking it.
Findability is the whole product
Staff do not browse a procedure library. They search once, in a hurry, using the words they would use out loud. Test that: pick a task, ask someone to find its procedure without being told the title, and time it.
Test Findability in One Attempt
- Pick a task staff actually do
- Ask someone to find its procedure
- Do not tell them the title
- Time how long the search takes
- Check titles are verb phrases
- Check the document address survives versions
Two structural things help more than any search feature. Titles written as verb phrases, so the search terms match what people are trying to do. And a stable address per document that survives a new version, so a link from a training note or a meeting document keeps working.
The plain wording that makes search work is the same wording that makes procedures followable, which the federal plain language guidelines set out at length.
What to ignore in a demonstration
What to ignore
- Template libraries. The substance of a procedure is yours, and a supplied template for your task does not know your systems.
- Automatic generation from a recording or a transcript. It produces a description of one run of the task, including the mistakes, and it never contains the stop rule.
- Read receipts presented as compliance. They measure distribution. What measures whether a procedure works is the task coming out the same way, which lives in whatever system already logs the work.
- Any dashboard whose main number is document count.
Offline, print, and the shop floor
Ask how a procedure is used where it is used. If that place has poor signal, gloves, or no screen, the tool must produce a clean printable version. It needs a way to tell a printed copy from a current one.
A version number and review date visible from a distance do that. The same constraint shapes the printed version of an operational checklist, often posted at the same machine.
Where documents get printed and posted, retention becomes a real question: the National Archives' notes on records management policy are a useful model for deciding in advance how long superseded versions are kept and who removes them.
A trial script worth an afternoon
A trial script
- Create a procedure using the house structure.
- Publish it, then correct one step as an ordinary user.
- Look at the change note the tool produced and see whether it names the behavior that changed.
- Search for the document using a word from the middle of it.
- Open it on the worst device in the building.
- Revise it twice more, then ask the tool for the version live on day one.
- Export everything and open the files elsewhere.
Steps three, six, and seven separate the candidates. Everything passes steps one and two.
When a shared folder is enough
A team with a handful of procedures, one owner, and a habit of verifying by performance can run on files in a well-named folder, provided superseded versions are moved rather than overwritten.
The case for a tool starts when several people author, when you need to prove what was in force on a date, or when the documents are read somewhere the folder is not reachable. The same trial logic applies to the tools that hold policy documents, and the two often end up in one system.
