SOP University · Lesson 9 · Buying SOP software · 20 Sep 2026
How to Write Requirements for SOP Software
Best SOP Software reviewers · From vendor pricing, help-centre and product pages · Evaluated September 2026
Plain answer
Write requirements from your SOP lifecycle, not from a vendor's feature list: for each stage from draft to revision, write what must happen, who does it and what record it must leave. Mark each requirement as must-have or nice-to-have, note the plan it needs, and use the list to shortlist tools and script demos.
Which requirements come from each stage?
| Stage | Example requirement |
|---|---|
| Draft | A subject expert can produce a first draft of a 10-step software task without help. |
| Review | A second person can comment on a draft before it goes to approval. |
| Approve | Only named approvers can approve, and each approval is recorded with a name and date. |
| Publish | Staff see only the current version; earlier versions are marked as superseded. |
| Train | We can assign an SOP to a role and see who has confirmed the current version. |
| Audit | We can show who created, changed, approved and read each version, and when. |
| Revise | Version history is kept for at least as long as our record retention period. |
What else belongs in the list?
- Sign-in: single sign-on, and automatic user provisioning through SCIM if you have many users.
- Security evidence: the reports your security team asks vendors for, such as a SOC 2 Type II report.
- Where SOPs must appear: wiki, help desk, learning system or chat, and the export formats that needs.
- Regulated records: whether any SOPs are FDA-regulated records, in which case 21 CFR Part 11 applies.
- Budget and seats: how many people need a paid seat, and whether the vendor counts users, members or creators.
How do you turn requirements into a shortlist?
Weight the categories the way your team works. The calculator does this with our seven criteria and shows published costs at your seat count. Then check each must-have against the plan you would buy, because governance features are often plan-dependent: approval flows start on Whale's Advance plan, audit logs and 365-day history are on Tango Enterprise, and SCIM is on the Enterprise plans of Haiku and Scribe.
How do requirements feed the trial?
Each must-have becomes a step in your trial script, run on your own SOPs rather than a demo task. Our trial checklist turns the lifecycle into ten steps on three real SOPs.
What should you leave out?
Features that no stage of your lifecycle needs. A long list of nice-to-haves makes every tool look alike and hides the few requirements that separate them. If a requirement would not change which tool you choose, move it to a separate list for later.
Key terms: SCIM, Single sign-on (SSO), SOC 2 Type II, 21 CFR Part 11, Proof of concept (POC)