How Do You Create SOPs Your Team Will Actually Use?

To create SOPs your team will actually use, document one real workflow, explain the decisions that require judgment, and test the instructions with someone who needs them. A useful SOP helps a person complete the work or recognize when to ask for help. It is not simply a record that a process exists.

For an operations director at a growing nonprofit, the starting point is often a familiar interruption: staff repeatedly ask how to handle the same request. Choose one of those recurring questions before committing to a large documentation project.

Start with the work, not the template

Ask an experienced staff member to walk through a recent example. Where did the work begin? What information was missing? Which decision required another person's approval? Where was the finished record stored?

Compare that account with the official process. If staff must work around a broken step, copying the official version will preserve the problem. Resolve the disagreement with the process owner before writing instructions that everyone is expected to follow.

Keep the first SOP narrow. "Handle a new service inquiry" is easier to test than "Manage all program operations." Link to related procedures instead of repeating them in several documents.

Include the decisions between the steps

A sequence of actions is helpful, but staff also need to know what counts as ready, complete, or outside their authority. Make those boundaries visible.

Include	Question it should answer
Starting condition	When should I use this procedure?
Required information	What do I need before beginning?
Owner and backup	Who moves this work forward?
Decision boundary	What can I decide, and what needs review?
Completion check	How do I know this is finished correctly?
Exception route	What happens when the usual steps do not fit?

Use plain language and the names staff see in their tools. Avoid instructions such as "process appropriately" unless the next sentence explains what that means.

Test it without narrating every step

In a hypothetical example, a nonprofit creates an SOP for scheduling an intake conversation. A staff member unfamiliar with scheduling tests it using a fictional inquiry. The steps explain how to offer an appointment but not what to do when no accessible appointment option is available.

That gap is useful evidence. Add the escalation contact and the information that person needs. Do not treat the tester's question as a failure to read carefully.

Ask the tester to point out unclear terms, missing access, and decisions they could not make. Use a practice environment or fictional record so the exercise does not expose client information or disrupt service delivery.

Put the reference where work happens

Keep one maintained version in a place staff can reach. Link to it from the relevant checklist, shared workspace, or onboarding plan. Assign an owner and a review trigger, such as a changed tool, changed responsibility, or repeated exception.

Keep detailed background separate from the quick reference when that helps readability. Someone completing a routine task should not have to search a long policy narrative for the next action. Accessibility matters here too: readable text, descriptive links, and instructions that do not depend on color alone.

Look for use, not just completion

After staff try the SOP, ask whether they could find it, follow it, and recognize an exception. Notice where clarification is still needed. Those observations are more useful than counting how many documents were produced.

Bring one recurring question to your next team check-in. Agree on its owner, draft the procedure together, and test it with a colleague. For help deciding which process deserves attention first, use the guide to finding workflow bottlenecks. Begin with a reference that makes one piece of work easier, then build from what the team learns.

---

Oh, and here's something I made for leaders wondering what their everyday operations might be costing them: Take the Operations & Funds Check