Revising an SOP without losing the old version

SOP versioning means a dated revision with the previous text kept, an effective date for the new steps, and a decision about who must re-read. The object is the procedure over time, not a silent overwrite of the only copy. Owner of the revision is the procedure owner; owner of chasing re-acknowledgement is whoever owns receipts. Product surface is Dayzen SOP management, which includes revision control (and assignment rules, categories, My SOPs receipts, compliance reports, welcome assignment on activation). How people acknowledge, and how you report outstanding readers, lives on SOP read receipts and compliance reports — this page will not retell that chase. The SOP template still owns document structure. This page is effective dates and archives. It is not a writing-craft lesson and not a claim that old acknowledgements automatically cover new steps.

Why overwrite feels faster and costs more

Someone edits the live file, saves, and tells Slack it is updated. Last month’s dispute then has no text to compare. A customer asks what people were told in Q1 and you only have Q3. A reader who acknowledged in January still looks “done” while the steps changed in June. Versioning is the discipline that prevents those three failures from being the same afternoon.

Keeping old text is not nostalgia. It is how you explain why a person followed a different path on a dated case. Destroying the only copy is how every investigation becomes a memory contest.

What a version is

A version is a snapshot of the procedure that was (or will be) in force: identity of the SOP, revision label or number you use, effective date, who approved the change, and the body of the steps at that time. The current version is the one assigned readers should follow from the effective date. Prior versions remain readable as history, not as competing live instructions.

Dayzen SOP management includes revision control. Use it as the archive. Do not keep the “real” SOP in a desktop file and the HRMS as a copy you forget to update. Two archives is how you pick the convenient one after an incident.

Rich-text authoring still happens on the current draft; revision control is what happens when that draft becomes the live procedure without erasing what came before. The product does not generate the new steps with AI. A human still writes the change.

Effective date is a decision

An effective date answers when the new steps apply. It can be immediately on publish, or a future date you communicate. Mid-cycle changes (leave close week, payroll week, a customer go-live) need a chosen date so people are not following two sequences on the same morning. Write the date on the procedure. Do not rely on “from when I hit save” if save is not the operational moment.

If the policy changes on a different date than the SOP, say so. Rules and steps should not silently disagree for a week unless you intended a transition and wrote it. Taxonomy of policy versus SOP is a sibling; here you only refuse to let dates drift without a sentence.

Effective dates are operational. What the law expects for a particular topic may depend on applicable law, contract, policy, or company practice. This article is not legal advice and does not invent a mandatory notice period for SOP changes.

Who must re-read

When steps that change how the job is done go live, decide the audience that must acknowledge again. Often that is everyone currently assigned. Sometimes it is only the roles whose steps changed (packers, not finance). Sometimes a typo fix does not justify a re-read. That decision is yours; revision control does not magically know materiality.

Re-read is executed as receipts: outstanding acknowledgements against the new version, visible on compliance reports. The mechanics of My SOPs and reports are on the read-receipts sibling. This page’s job is to force the question before you publish: who must confirm the new text, and by when?

Do not treat last year’s receipt as covering this week’s procedure unless you have explicitly decided the change is non-material. Do not flood every employee with a re-read because you changed a category label. Match the audience to the change the way you match assignment to role.

A comparison you can paste into a RACI

	Current SOP	Prior version (archive)	Re-read / receipt
Object	Steps in force from the effective date	Text people were asked to follow then	Dated acknowledgement of a specified version
Typical owner	Procedure owner	Same owner; HR as archive admin	Assigned reader; HR chases (see receipts sibling)
Artefact	Live procedure in SOP management	Revision history via revision control	My SOPs receipt and compliance report
Done when	Audience can follow today’s job	Old text still retrievable	Required people confirmed the version you named
Failure mode	Silent overwrite, no date	Desktop copy only, then lost	Green report on an obsolete version

How to change a procedure without a mess

Draft the change in rich text. Name what changed in a sentence a manager can forward (“step 3 now requires the delegate field; step 5 cutoff moved to the published leave-close calendar”). Set the effective date. Publish under revision control so the previous body remains. Then apply assignment rules to the people who should see the current version — Dayzen includes assignment and distribution rules; do not rely on forwarding a Word file of vNext.

If joiners should see only the current welcome material, that is welcome SOP assignment on activation, not a reason to delete history. History is for the people who must explain the past; joiners need the live job.

If a change is a full rewrite, still keep the old version. A rewrite is the case you will be asked about later. If a change is a correction of a dangerous step, shorten the effective date and widen the re-read; do not hide the old dangerous step by deleting it from memory. You may mark it superseded. You should still be able to show it.

Communicate the effective date in the same channels you use for assignment — My SOPs will show the current text, but managers still need a sentence they can repeat. “v4 from Monday; until then follow v3” is operational. “Please note the SOP has been updated” is how half the team switches early and half never switches. If two sites cannot cut over on the same morning, say so in scope rather than publishing one body and hoping local custom fills the gap.

Do not fork a “temporary SOP” in a side document for a week of exception handling unless you are willing to version that too. Side documents become the real procedure and then vanish. Put the exception in the exceptions section of the current version, with an end date if the exception is time-boxed, and revise again when the box closes.

What not to mix into the archive

Do not store policies as SOP versions. A leave-policy reissue is a policy object. You may revise the leave-approval SOP because the policy changed; those are two histories. Do not store handbook PDFs as SOP revisions. Do not use version comments as a substitute for exception paths in the template.

Do not claim revision control is statutory training history, POSH attendance, or a filing. It is procedure history. Receipts against versions are operational reading proof, described on the sibling — still not a training certificate by themselves.

Name who may publish. If anyone with edit access can make a revision live, you will get formatting nits that trigger unnecessary re-reads and material changes that go out with no owner sentence. A simple rule: the procedure owner publishes; contributors draft. Revision control records what went live; it does not replace that social rule.

What this page will not become

It will not become the read-receipts article. You will link it when someone asks how to chase outstanding acknowledgements. Versioning decides whether a chase is required; receipts run the chase.

It will not become the SOP template or the writing-craft guide. New sentences still need purpose, scope, steps, and exceptions. Versioning packages those sentences over time.

It will not become role-based assignment strategy, except to say that the current version is what rules should distribute. It will not link helpdesk. It will not claim AI generation or AI search.

Language to use in status updates

Prefer:

• “Regularisation SOP v4 effective 1 July; v3 archived in revision control; packing SOP unchanged.”
• “Re-read: all currently assigned managers by 8 July; typo-only SOPs skipped.”
• “Receipts and outstanding names: see the compliance report on the receipts process — not this email.”

Dated revision, old text kept, effective date said out loud, re-read decided on purpose. If you only hit save, you have an overwrite, not a version.

Keep Dayzen SOP management revision control as the archive for procedures. Keep read receipts on the sibling for acknowledgement and reports. Keep owners named on each revision. When the job changes, change the version in the system — not in a private copy — and then ask who must confirm the new steps before you call the organisation “updated.”