What a Standard Operating Procedure Is, and When Your Small Nonprofit Needs One

You run a six-person nonprofit, you have no IT support, and your board has started using the words “process” and “documentation” in the same sentence. The question underneath is whether you should spend a Saturday writing standard operating procedures, or keep running on shared inboxes and the assumption everyone knows their job.

A standard operating procedure is a written checklist for a recurring task. You need one for any task that breaks when the usual person is out, which for most six-person nonprofits is three or four documents, not a manual. What follows is a definition that holds up in a board conversation, a test for which tasks justify the effort, and the smallest version that works.

What a standard operating procedure actually is

A standard operating procedure is a written, step-by-step set of instructions for performing a recurring task the same way each time.

The FDA Group, summarising practice in regulated industries, defines an SOP as “step-by-step instructions for performing operations” so personnel do them correctly and consistently. Both words in the name carry weight. Standard means the task is done the same way each time, regardless of who is doing it. Operating means it is the actual work that gets done, not a policy adopted at a board meeting and then never touched.

An SOP is not a policy, a workflow diagram, or a job description. It sits below all three. It is the literal sequence of steps for one task, written in plain language, short enough that the person doing the task will actually open it.

Does a six-person nonprofit need SOPs?

Yes, but fewer than you think. Most six-person nonprofits land on three or four documents covering the tasks that break when the usual person is out.

The operative rule is the bus-test. If the person who normally does this task got hit by a bus tomorrow, could a colleague pick it up on Monday using only what is written down? If no, it needs an SOP. If yes, it does not. The bus-test sounds grim but it is the same question your auditor or your funder would ask in less colourful language.

The structural case for SOPs at small orgs is the opposite of what most people assume. Project-management literature suggests an ideal team bus factor of 3 to 5 people minimum for resilience, which a six-person nonprofit cannot meet across every function. You depend on SOPs more than a fifty-person org does, because there is no bench to absorb absences. And the typical threshold for a first dedicated operations hire is 15 staff. At six staff, the SOPs are doing the work a Director of Ops would otherwise hold in their head.

The second filter is the audit-trail test. If a funder, auditor, or board member asks how something happened six months from now, can the records reconstruct it? If no, the procedure for creating those records needs an SOP. Tasks that pass both tests do not need one.

Which tasks at a small nonprofit are SOP-worthy?

The candidates are gift acknowledgement, grant submission, payroll, board pack assembly, and monthly financial close. Most six-person orgs need three of those five, not all of them.

These are the tasks that recur often enough to justify writing down once, and that fail one or both of the tests above. Run each through the bus-test and audit-trail test honestly.

• Gift acknowledgement. If the usual sender is out two weeks, gifts pile up and the donor relationship cools. Tax-receipts also need an audit trail. SOP-worthy.
• Grant submission. Funder portal logins, budget template, and narrative structure all live in one head. SOP-worthy.
• Payroll. People do not get paid if the usual person is out. Audit-trail required by law. Non-negotiable.
• Board pack assembly. SOP-worthy if your board materials are non-trivial. Can stay informal if the pack is two PDFs and a P&L.
• Monthly financial close. Required for any external audit. SOP-worthy.

What does not make the list at this size: social media posting, event setup, individual donor research, volunteer onboarding. The rule is severe on purpose. Anything that does not fail one of the two tests stays as informal practice.

What a usable nonprofit SOP looks like

One to two pages, plain language, owned by one named person, stored where the task happens. Anything longer dies on the shelf.

If an SOP runs past two pages for a task a small nonprofit actually does, the document has drifted from “checklist” into “manual”. The FDA Group warns that SOPs containing too much material create their own compliance risk because nobody reads them and the parts that matter get missed.

Format: numbered steps, plain sentences, screenshots only where the screen is the documentation, a one-line purpose statement at the top, and owner name plus last-updated date in the header. That is it.

Storage matters more than format. The gift acknowledgement SOP belongs in the CRM’s documentation tab or pinned in the donor-data folder. The payroll SOP belongs next to the payroll tool’s login. A central “policies” folder in Google Drive is where SOPs go to die. Organise around the team’s actual work categories rather than around an abstract library. The document lives where the work lives.

The five-step SOP process for a small org

Five steps, in order. None of them require a template, a tool, or a Saturday. The whole approach is: written by the doer, while doing the task, for one named owner, stored findable, reviewed at next reuse.

Write while doing

The first draft is written by the person doing the task, while they are doing it, in plain language. Not ahead of time by someone who imagines the task. Not afterwards from memory. The doer narrates each step into a doc as they go, or screen-records with voice notes and cleans up later. The output will be rough and that is correct. A rough document the doer wrote in 30 minutes during a real run beats a polished one a consultant wrote from an interview.

Name the owner

One named person owns the SOP. Not a role, not a team. The owner approves edits, decides when the document is stale, and is the person to ask if the steps do not match reality. Without an owner, the SOP fragments into incompatible copies within months. ThinkFuel makes the same point about CRM data: governance prevents problems where hygiene only fixes them. An SOP without a named owner is hygiene at best.

Store where the task happens

The SOP lives in or next to the tool used for the task. Gift acknowledgement SOP in the CRM. Payroll SOP next to the payroll tool. Grant submission SOP in the funder portal folder. Not in a central “policies” folder, because the doer will not navigate there mid-task. The test is whether the person doing the task can open the document without leaving the screen they are working on.

Review at next reuse, not on a calendar

Calendar-based review fails at small nonprofits because nobody has time and the reminder gets dismissed. Review at next reuse means the owner opens the SOP the next time they do the task and asks one question: does this still match what I am actually doing? Edit in place if no. Mark the date and move on if yes. No formal review meeting.

Retire when the task changes

When the underlying task changes, say a new CRM or a new funder portal, archive the old SOP rather than editing it. Editing carries forward steps that no longer apply and produces a hybrid that matches neither old nor new. A fresh write-while-doing pass on the new task is cleaner and faster. Keep the old version archived so the audit trail survives, but do not work from it.

Where SOPs fail at small nonprofits

Two failure modes do most of the damage at this size: outdated content and lack of accountability. Over-documentation is the third, and it usually comes from good intentions.

Collaboris reports five common reasons SOPs go ignored: lack of clarity, resistance to change, forgetfulness, lack of accountability, and outdated content. At a six-person nonprofit, the last two fire most often. Documents drift from reality because nobody owns them, and once they have drifted, nobody trusts them.

The same dynamic shows up in shadow-IT research. Workarounds inside small finance and ops teams are usually practical rather than malicious. Staff build their own systems when the documented one does not match the work. The structural cause is lack of governance. If your team is ignoring an SOP, the SOP is wrong, not the team.

Over-documentation usually comes from a board member asking for “more process”. Writing twenty SOPs erodes trust in the three that matter, because the team learns the documents are aspirational rather than operative. If your nonprofit has three working SOPs and the rest of the institutional knowledge lives in heads, you are doing better than most peers your size. The goal is not coverage. The goal is that no single illness puts the org in crisis.

SOPs and AI: should you have the chatbot write them?

Yes for the first draft from a transcript or screen recording. No for ownership. AI is a transcriber, not an author.

The mechanic is straightforward. The doer screen-records themselves doing the task once with voice narration. The recording goes to ChatGPT, Claude, or a similar tool with a prompt like: “Turn this into a numbered checklist a colleague could follow on Monday. Plain English. Mark anything ambiguous.” The doer reads the output, fixes what the model misheard, and saves it. About an hour for a task that would take three to write up cold.

This works because the FDA Group’s rule for SOP authorship still holds. SOPs “should be written from a purely practical perspective from the point-of-view of those who will actually use them”. The doer is still the author. The model handles transcription and structure, which is what it is good at. Judgement about whether the document matches reality stays with the human.

What does not work: asking the model to write an SOP for a task it has never seen you do. The output looks plausible and is wrong in ways hard to spot until the day you actually need it. Susan Mernit’s nonprofit AI work frames the same boundary, treating custom GPTs as thought partner, not replacement. The tool saves you the typing. The judgement is still yours.