Building your first church SOP

You are probably here because someone left, a volunteer, a staffer, sometimes a pastor, and the office discovered mid-task that nobody else knew how the check-in system worked, how the giving count actually ran, or who had the password to the email platform. It was never written down. This post fixes that, one page at a time, as part of our guide to the church operations playbook.

CoLabor Staffing places full-time Christian co-laborers with churches and Christian-owned businesses. A written SOP is also the fastest way to hand a task to a co-laborer cleanly, though the template below works the same whether the next person to run the task is a new hire, a volunteer, or the person already doing it who just wants it out of their head.

What actually counts as a task worth writing an SOP for?

Two questions decide it. Does the task happen more than once? Would someone else eventually need to do it, whether that's a backup this month or a replacement next year? If both are true, it's worth the page. A one-time task, like planning a single anniversary event, isn't. A weekly or monthly task that only one person understands is exactly the kind of task this is for.

Run that test against a normal church office and the list gets long fast: the Sunday guest card process, the weekly giving deposit, entering visitor cards into the database, the volunteer confirmation sequence, the newsletter send, opening and closing the building, running background checks on new volunteers. None of these are complicated once someone knows them. All of them stop the office cold if the one person who knows them is suddenly gone.

What are the five parts of a church SOP?

A fifth part sits underneath all four: the tools or access the task requires, logins, software, physical keys, so the backup person isn't blocked on day one by a password nobody gave them.

None of these five parts needs more than a sentence or two, except the numbered steps. That's on purpose. An SOP that tries to explain the theory behind a task, why the church does a background check this particular way, or why the giving count follows this specific two-person rule, stops being something a new person can execute from and starts being an essay. Save the reasoning for a conversation. Keep the page itself down to what someone actually does, in order.

What does a filled-out example look like?

Here's the five-part format applied to a real recurring task, the Sunday guest card follow-up. Fill in the bracketed lines and adapt the steps to your own process.

This example mirrors the full 72-hour guest follow-up process; adapt the same five-part shell to any other recurring task in your office.

Who should write the SOP, the person doing the task or their supervisor?

The person doing the task writes the first draft. They know the actual steps, including the small workarounds and judgment calls that never make it into a job description. A supervisor writing it from the outside will describe the task the way they imagine it works, not the way it actually runs. The supervisor's job is the review pass afterward: checking for gaps, confirming the steps are specific enough for someone new, and signing off.

This order matters more than it looks like it should. Ask a supervisor to write the SOP first and they'll produce a clean, logical document that skips the one step that only matters because the printer jams on humid days, or the reason the deposit always gets counted in a specific order. Ask the person doing the task and you get the real process, warts included, which a supervisor can then tighten without losing the part that actually makes it work.

Where should SOPs actually live so people find them?

One shared, findable location that anyone on staff can reach without asking permission, a shared drive folder or a wiki page works fine. What doesn't work: buried in someone's personal email, saved to a laptop that leaves with them, or scattered across a dozen individual documents with no index. If a new hire can't find the SOP in under a minute, it doesn't functionally exist yet.

An index page helps more than it seems like it should: one document, or one folder view, listing every SOP the office has by task name, so a new person can scan the whole list and see what's documented and what isn't. Without it, SOPs tend to pile up in whichever tool the person who wrote them happened to prefer, and nobody else knows to look there.

Where SOPs go wrong, and the fix

Where it goes wrong	Why	The fix
Buried in a personal inbox	Only searchable by the person who saved it	Move to a shared drive folder everyone can access
Saved to one person's laptop	Leaves the building when they do	Cloud storage, not local files
Written once, never reviewed	Drifts out of date silently	Set the three review triggers below
No index or list	Nobody knows what's already documented	One page listing every SOP by task name

Common failure patterns we see in church offices, with the straightforward fix for each.

How do you keep SOPs from going stale?

Three review triggers, not a set-it-and-forget-it document:

• Whenever the process changes. A new ChMS, a new check-in system, a new approval step, all mean the SOP needs an update the same week.
• Whenever the person changes. The outgoing person's last task before leaving should be updating the SOP with anything they've been carrying in their head instead of on the page.
• At least once a year regardless. A standing calendar reminder to reread every SOP catches the small drift that happens even when nothing officially changed.

A stale SOP is worse than no SOP in one specific way: it gives false confidence. A new person follows the written steps exactly, hits a wall because the ChMS changed platforms eight months ago and nobody updated the document, and now has both a broken task and a reason to distrust every other SOP in the folder. The annual review exists specifically to catch that kind of quiet drift before a new person finds it the hard way.

What should you write an SOP for first?

Not the biggest task. Not the most complicated one. The single task that would hurt the office most if the one person doing it disappeared tomorrow without warning. For most churches that's guest follow-up, the giving count, or whoever holds the passwords to the church's communication platforms. Start there, and let the rest of the office's tasks get documented as they come up naturally, often inside a staff meeting when someone asks "wait, how does that actually work?"

A useful way to find that first task, if it isn't obvious: ask each staff member privately what they do that nobody else on the team could explain step by step. The answers cluster fast, usually around three or four tasks total, and whichever name comes up most often is the one to write down first. Nobody needs a full documentation project to start. One page, this week, on the task that keeps you up at night, is enough to begin.

This is the exact kind of process a co-laborer runs from once it's written down. If it isn't written down yet, that's fine too, that's often where the work starts. See how it works.

Common questions