HR operations
HR SOP Starter Kit
Most small companies have HR processes. Very few have them written down, which is the same thing as having them stored in one person’s memory. This is how to get the important ones out of somebody’s head and onto a page — with a blank template at the end you can copy straight into your own document.
Who it is for
- Founders whose HR knowledge lives with one long-serving person
- First HR hires arriving into a company with nothing documented
- HR managers preparing to delegate or to go on leave
- Companies growing past the point where everybody just knows
What it helps with
- Get a process out of one person’s head and into a document
- Decide which processes are worth documenting first
- Write an SOP somebody can actually follow without you
- Keep SOPs current instead of writing them once and abandoning them
What an HR SOP actually is
A standard operating procedure is a written description of how one process runs: what triggers it, who does what, in what order, by when, and what exists at the end. It is not a policy. A policy says what the company has decided — twelve days of casual leave a year. An SOP says how that decision is carried out — how leave is requested, who approves it, what happens when the approver is away, where the record ends up.
The practical test is simple: could a capable person who has never done this job run the process correctly using only this document? If they would still need to ask you a question, the SOP is not finished.
Why a small company needs them
The honest counterpoint: writing SOPs for a five-person company is usually a waste of a good afternoon. The value appears at the point where more than one person runs the same process, or where the person who runs it needs to be able to stop.
Which processes to document first
Documenting everything at once fails. Frequency times cost of failure is the order that works.
| Process | When to write it | Why in that order |
|---|---|---|
| Payroll inputs | First | Runs monthly, has a hard deadline, and mistakes cost money and trust at the same time |
| Onboarding | First | Happens often, involves five different people, and a bad one is visible to the person it happened to |
| Leave and attendance | First | Applied to everyone every month; inconsistency here is what employees notice fastest |
| Exit and offboarding | Second | Less frequent, but the failures are expensive — assets, access, settlement |
| Recruitment | Second | Involves people outside the company, so a dropped step is visible externally |
| Performance reviews | Second | Runs once or twice a year; usually fails from vagueness rather than from missing steps |
| Employee data changes | Third | Small and frequent — worth documenting once volume makes it error-prone |
| Grievances and escalation | Third | Rare, but the one you least want to improvise. Take advice on this one |
Three SOPs that are used beat twelve that were written in one enthusiastic week and never opened again. Write the first three, use them for a month, and only then decide what is next.
The structure that works
Ten sections, and the order matters more than the headings. Somebody following a process needs to know why it exists and whether it applies to them before they need step four.
How to write one, in about ninety minutes
Watch it happen once
Do not write from memory. Run the process, or sit with the person who does, and write down what actually happens rather than what is supposed to.Write the steps in plain order
Short sentences, one action each. "HR emails the candidate the document list" beats "documentation is initiated".Name roles, never people
Priya leaves. The reporting manager does not. Every SOP that names an individual expires the day they change jobs.Put the timings in
A step with no deadline is a step that slips. "Within two working days" is a process; "promptly" is a hope.Have somebody else run it
Hand the draft to a colleague who does not do this job and ask them to follow it. Every question they ask is a gap in the document.Date it, version it, and set the review date
Before you publish it, not afterwards. An undated SOP is one nobody can tell is stale.
Ownership, review and versions
Every SOP has one owner, and the owner is a role
The owner is responsible for the document being correct — not for doing every step in it. Where nobody owns an SOP, it goes stale without anybody being able to say when.
Review on a date, not on a feeling
Annually is enough for most HR processes; anything touching payroll deserves a look every six months. Put the next review date in the header so it is visible to whoever is reading it, and diarise it.
Version numbers, and one live copy
Whole numbers for a change in how the process runs, decimals for a correction. Keep one live document that everybody links to, rather than a file that gets emailed around and forked. Three people holding three versions is worse than nobody holding any, because everybody believes they are right.
The blank template
Copy this into your own document and fill it in. Plain text on purpose, so it pastes cleanly into Google Docs, Word, Notion or a wiki without dragging formatting behind it.
SOP: [Process name] ================================================================ SOP number: HR-00 Version: 1.0 Process owner: [Role — not a person's name] Approved by: [Role] Effective from: [DD Mon YYYY] Last reviewed: [DD Mon YYYY] Next review due: [DD Mon YYYY] 1. PURPOSE ---------------------------------------------------------------- Why this process exists, in two sentences. What goes wrong when it is not followed. 2. SCOPE ---------------------------------------------------------------- Who this applies to, and who it does not. Any locations, employment types or situations that are excluded. 3. WHO IS INVOLVED ---------------------------------------------------------------- Role Responsible for -------------------- ---------------------------------------- [Role] [What this role does in this process] [Role] [What this role does in this process] [Role] [What this role does in this process] 4. WHEN THIS RUNS ---------------------------------------------------------------- The trigger. A date, an event, or a request. Include any deadline or cut-off that applies. 5. WHAT YOU NEED BEFORE STARTING ---------------------------------------------------------------- - [Document, access, approval or information] - [Document, access, approval or information] 6. THE STEPS ---------------------------------------------------------------- Step 1 — [What happens] Who: [Role] How: [Where it is done and how] Timing: [By when] Output: [What exists afterwards] Step 2 — [What happens] Who: [Role] How: [Where it is done and how] Timing: [By when] Output: [What exists afterwards] Step 3 — [What happens] Who: [Role] How: [Where it is done and how] Timing: [By when] Output: [What exists afterwards] 7. EXCEPTIONS AND ESCALATION ---------------------------------------------------------------- What to do when the normal path does not apply. Who decides. Who is told. 8. RECORDS ---------------------------------------------------------------- What is kept, where it is kept, who can see it, and for how long. 9. RELATED DOCUMENTS ---------------------------------------------------------------- - [Policy, form or other SOP this depends on] 10. VERSION HISTORY ---------------------------------------------------------------- Version Date Changed by What changed ------- ------------ ----------- --------------------- 1.0 [DD Mon YYYY] [Role] First version
How to use it
- Pick one process — payroll inputs is usually the highest-value first one — and copy the template into a fresh document.
- Fill in sections 1 to 5 before you touch the steps. If you cannot state the purpose and the scope, the steps will not be right either.
- Write the steps by watching the process happen, not by recalling it.
- Give the draft to somebody who does not do this job and have them follow it. Their questions are your gaps.
- Set the next review date before publishing, and diarise it. An SOP with no review date is a document that will quietly stop being true.
Common mistakes
Writing twelve at once
A documentation week produces twelve SOPs, of which two are ever opened. Write three, use them, then write more.
Naming people instead of roles
The single most common reason an SOP expires. Roles outlive individuals.
Describing the ideal rather than the actual
An SOP that describes how the process ought to run is a wish list. Document what happens, then improve it deliberately in version 2.0.
No owner and no review date
Both are in the header for a reason. Without them there is no way to tell whether a document is current, and people stop trusting all of them.
Too much detail
Nobody reads four pages to find out how to approve leave. If a step needs a screenshot and three paragraphs, the process is probably too complicated, and simplifying it beats documenting it better.
Written once and never opened
The test of an SOP is whether somebody used it last month. If not, either the process changed and the document did not, or it was never the document people actually work from.
Where to go next
Flabido keeps the everyday HR work of a growing Indian company in one place — people records, leave, attendance, payroll inputs, hiring and letters. See what it does or ask for a free trial.