How to write an operational SOP people will follow

An operational SOP people will follow is a short how-to for a named job, not a policy essay and not a generated wall of text. Writing craft is the object on this page: purpose, scope, owner, prerequisites, numbered steps, exceptions, evidence, then review and version. The skeleton of those sections is owned by the SOP template — do not invent a second field list here. Authoring in the product is rich text on Dayzen SOP management (categories, assignment, receipts, revision control, welcome assignment on activation). Dayzen does not auto-generate SOPs. It does not invent the procedure for you with AI. This page is how a human writes steps someone can use today. It is not the template reprint, not a policy handbook, and not a click-by-click product tour.

Why most “SOPs” are not followed

They are too long, they mix rules with clicks, they name no owner, they skip the ugly path, and they live in a file nobody opens on the day of the job. People then learn from the nearest colleague and the document becomes decoration. Craft is the fix: write the job as a sequence a competent new holder of that job could complete without a hallway briefing, then stop.

If the real problem is an unissued rule, write a policy first. If the real problem is that the wrong people received the file, that is assignment. If the real problem is last quarter’s steps still on screen, that is versioning. This page assumes you are drafting or redrafting the procedure text.

Write in this order (craft, not a new template)

Use the SOP template’s sections. Fill them in an order that prevents waffle. Purpose through version below is writing advice sitting on that skeleton — not a competing outline you paste beside the template.

Purpose

One short paragraph: what job this procedure exists to complete, and what a good outcome looks like. “So that leave applications are decided before leave close” is a purpose. “To foster a culture of excellence” is not. If you cannot name the job in a clause, you do not have an SOP yet; you have a theme.

Scope

Who and what is in, who and what is out. Entities, locations, roles, systems. “Managers approving leave in Dayzen for Company A offices” is scope. “All HR” is usually too wide. Explicitly exclude the neighbouring jobs: “does not set leave types; see the issued leave policy.” Scope prevents the SOP from absorbing the handbook.

Owner

A named role (and a backup if you have one) who may edit the procedure and who answers “is this still right?” Owner is not “HR” as a building. Owner is not the last person who formatted the PDF. When the job spans functions, still pick one owner and list contributors. Unowned SOPs do not get exceptions updated; they get folklore.

Prerequisites

What must already be true before step 1: access, documents, prior approvals, time of month, tools. “Employee record is active” or “leave policy issued for this entity” are prerequisites. Hiding them inside step 4 is how people fail at step 1 and blame the SOP. Do not list every corporate value as a prerequisite.

Steps

Numbered actions a person does, in order, with the role who does each action if it changes hands. One action per step when you can. Name the screen or artefact in the language your team actually uses, not a metaphor. “Open the application, set decision, save” is a step. “Ensure alignment with stakeholders” is not a step.

Keep the happy path short enough to use under time pressure. If you need more than a screenful of steps, you may have two jobs. Split them rather than writing a novella. Dayzen stores rich text; it will not shorten your prose for you.

Exceptions

What to do when the happy path fails: missing document, approver on leave, system down, date in the past, employee already exited. Each exception should say who decides and what to record. “Ask someone” is not an exception path. If the exception is actually a policy (whether the request is allowed at all), point to the policy; do not re-legislate inside the SOP.

Evidence

What you keep so the job is auditable: the record in the system, a screenshot only if the system is not the record, a ticket number if you use one, a named folder if you must. Prefer the system of record over a parallel spreadsheet. Evidence is not a novel. Name the minimum that proves the step happened.

Review and version

When this procedure is reviewed, who signs that it is still accurate, and how a change becomes the current version (effective date, what happened to the old text). Revision control in Dayzen SOP management keeps versions in the product; writing craft still needs you to say what changed in human language. Do not silently overwrite the only copy in a local file and call it “updated.” The versioning sibling owns the operations of effective dates and re-read; here you only close the draft with a review line so the template is not an empty footer.

Voice and length

Write like a competent colleague, in the imperative (“Open,” “Check,” “Record”). Avoid legal theatre in a how-to. Avoid screenshots of every pixel unless the UI is genuinely ambiguous; they rot faster than sentences. Avoid pasting policy quotas and statutory section numbers into steps — those go stale and this page will not invent them.

If a step depends on applicable law, contract, policy, or company practice, say “follow the issued policy for X” rather than restating X. This article is operational guidance, not legal advice.

What Dayzen does and does not do for the writer

You author in rich text, file the SOP in a category, assign it with distribution rules, collect My SOPs receipts, and revise it under revision control. Welcome SOP assignment on activation can put a joiner procedure in front of new employees. None of that writes the steps. There is no AI generator that observes your floor and emits an SOP. There is no AI search that replaces a named procedure. If the text is vague, the product will faithfully distribute vagueness.

Do not wait for the HRMS to “suggest a procedure.” Draft against the template, have the process owner walk the job once, then paste the real sequence. A dry run on a throwaway case beats a beautiful first paragraph.

A comparison you can paste into a RACI

	This page (craft)	SOP template	SOP management
Object	How to write steps people use	Section skeleton and fields	Author, categorise, assign, receipt, revise
Typical owner	Process owner as writer	Template owner (do not fork)	HR ops as product admin; owner as author
Done when	A new holder can complete the job from the text	Sections present; not empty headings	Current text is in the system and assigned
Not this	Policy rules, handbook pack	Prose style, audience strategy	AI generation (not offered)

A worked shape (leave approval, not a second policy)

Purpose: managers decide leave applications in time for leave close. Scope: managers in entities that use Dayzen leave; excludes setting types and balances. Owner: HR operations for the procedure; managers execute. Prerequisites: issued leave policy, manager access, application in the system. Steps: open queue, check dates and type against policy, approve or refuse with a reason, save before the published cutoff. Exceptions: manager absent — named delegate; application after freeze — follow the issued exception rule, do not invent one here. Evidence: the decision on the application record. Review: each time the leave policy or the screen changes, and on a planned calendar.

That sketch is craft. The leave-policy template remains the rules outline. Do not copy quotas into these steps.

What this page will not become

It will not become the SOP template. If you need the heading list, open the template. This page teaches filling, not a parallel form.

It will not become receipts, role-based assignment, or welcome-SOP onboarding. Those siblings consume a written procedure; they do not draft it.

It will not claim Dayzen is an LMS, a helpdesk, or a policy CMS. It will not claim auto-generation. Project work belongs in the project management system if you use one; an SOP is not a project plan and PMS is not this topic.

Language to use when you hand a draft back

Prefer:

• “Purpose and scope are tight; steps 4–6 still say ‘coordinate’ — replace with a verb and a screen.”
• “Exceptions missing for approver leave; add a delegate, do not add a new leave type.”
• “Owner is a mailbox; name a role. Evidence is ‘keep emails’; point at the application record.”

Purpose, scope, owner, prerequisites, steps, exceptions, evidence, review. If a sentence cannot be done at a desk today, it is not a step yet.

Keep the SOP template as the field owner. Keep Dayzen SOP management as rich-text authoring without pretending it writes for you. Keep policies and handbooks off this page. Write the job, walk it once, then assign the current version — generation will not appear as a button, and that is intentional.