Under construction: QMS is still being actively built, and there's no guarantee your data won't be lost as we keep changing things. Everyone's welcome to try it out anyway.
QMS gives every team its own workspace to draft, lock, and revise documents: Git-like version control for the policies, handbooks, and specs that usually live in "final_v3_FINAL.docx".
How it works
Not just hidden buttons in the UI: locking a version and starting the next draft are rules the backend holds, so what you see is what actually happened.
Write titles, paragraphs, and tables straight in the browser. Every field saves itself as you work, with no separate "save" step to forget.
When a version is ready, lock it. From that moment the server refuses every edit to it, stamped with who locked it and when, and it stays that way.
Need to revise a locked document? Start a new draft from it. The locked version never moves and still stands as the record; the new draft picks up numbering right where it left off (v1.1 locked becomes v1.2 draft).
What you get
A locked version can't be edited again, by anyone, ever. Who locked it and exactly when travels with the record, not in a separate log you have to trust.
Every draft and lock a document has ever gone through, in order, visible from the editor itself, not reconstructed after the fact from file names — with a blockwise diff to see exactly what changed between any two versions.
Starting a new draft picks up a locked version's content without disturbing it, so the approved copy stays exactly as approved while the next one is being worked on — one straight line of history, never a tree to reconcile.
Your workspace runs on its own subdomain, backed by its own database file, not a shared row in someone else's table.
Titles (H2-H5, numbered automatically), paragraphs, and tables are real elements the system understands, which is what makes locking a whole document and diffing it against an earlier version actually reliable.
Send a locked version to specific people and know precisely who it was sent to, right from the document itself.
Recipients confirm they've read and understood a document before it counts as acknowledged, with a record of who has and hasn't.
Who it's for
The ones an auditor asks for, not the ones a wiki page can replace. If you've ever had to prove which version of a document was in effect on a given date, that's the exact question a locked, timestamped version answers.
On the roadmap
Distribution and read confirmation work today — this is the one piece of keeping the recipient list current automatically that doesn't yet.
Pull distribution groups directly from M365, so the list of who needs a document stays current instead of manually maintained.
Stop trusting a filename to be your version control.