Operations Manual
Download this template
Generated 2026-08-31 · Download all templates
Core Operational Processes
Which things have to keep happening every week — and are they written down anywhere?
RCOS clauses 7.3.4, 7.7.2, 7.6.3
- 7.3.4 Critical operational processes MUST be documented such that continuity does not depend on tacit knowledge held by specific individuals.
- 7.7.2 Critical operational processes MUST NOT rely solely on individual memory, goodwill, or informal transmission.
- 7.6.3 The Operations Manual MUST define, at minimum:
Why document critical processes?
If a process only lives in one person's head, the community depends on that person showing up — forever. Writing the critical processes down, with named owners, is what converts private knowledge into a community asset that survives handovers, absences, and exits.
How to fill this in
For every recurring critical process (onboarding, exit, proposal publication, contribution recording, meeting cadence, treasury management, platform access review), name an owner and a brief description.
| Process | Who | Detail |
|---|---|---|
| <Member onboarding> | <role> | <see Onboarding Protocol (Layer 1)> |
| <Member exit> | <role> | <see Exit & Separation Protocol (Layer 1)> |
| <Proposal publication> | <role> | <see Governance Protocol (Layer 2)> |
| <Contribution recording> | <role> | <see Internal Economy Protocol (Layer 3)> |
| <Recurring meeting> | <facilitator> | <agenda publication; notes; action tracking> |
| <Treasury management> | <finance steward> | <see Treasury Ruleset (Layer 3)> |
| <Platform access review> | <infrastructure steward> | <review cadence; access revocation for exited members> |
What to cover
- Which processes have to keep happening for the community to work — onboarding, exit, publishing proposals, recording contributions, running meetings, managing money, reviewing platform access, and anything else?
- For each process: which role owns it, and what does it involve in two or three sentences?
- For each process: where are the steps written down, so someone new could carry it out without asking the person who usually does it? (Where our documents live in general is its own question.)
- Which of these still depends on one person's memory or goodwill — and who will write it up, by when?
- How do we keep each written process up to date when the way we actually do it changes? (Handoffs between roles are their own question.)
Examples
Our core processes are member onboarding and member exit (Membership Admin, following those protocols), proposal publication (Governance Secretary), contribution recording (Contribution Steward), the weekly meeting (rotating facilitator: agenda, notes, action list), treasury management (Finance Steward) and platform access review (Infrastructure Steward, monthly, removing exited members). Each has a one-page checklist in the shared handbook that a new role holder can follow without help, and the owner updates it within a week of any change in practice.
Examples, not recommendations. Your answers will be your own.
Temporary and Ad-Hoc Responsibilities
How do we stop a temporary favour becoming somebody's permanent unpaid job?
RCOS clauses 7.1.5, 7.1.4, 7.7.1
- 7.1.5 Temporary or ad-hoc responsibilities MUST be explicitly time-bounded and MUST NOT become ongoing without formal role definition.
- 7.1.4 No ongoing responsibility MAY exist without an explicit role, and no person MAY be held accountable for responsibilities not formally assigned to a role.
- 7.7.1 Ongoing responsibilities MUST NOT exist without an explicit role.
Why cap temporary responsibilities?
Ad-hoc tasks quietly calcify into permanent unpaid jobs — usually on whoever said yes once. A hard time-box and a forced review make the difference between "I covered for a week" and "apparently this is my role now."
How to fill this in
State that any temporary responsibility must be time-bounded at assignment, documented, reviewed before expiry, and either formalised or terminated.
When a task or responsibility is assigned temporarily, it must be:
- <Explicitly time-bounded from the outset (specific end date or completion condition).>
- <Documented as temporary at the time of assignment.>
- <Reviewed before the end date; converted to a formal role or terminated.>
<Maximum duration of any temporary responsibility before it must be formally assigned or terminated — e.g. 90 days.> If a temporary responsibility has no owner after its end date, it lapses; it does not transfer implicitly.
What to cover
- When someone takes on a temporary task, how is its end set — a date, or a clear condition that marks it done?
- Where is it recorded as temporary at the moment it is handed out, and by whom?
- What is the longest a temporary responsibility may run, extensions included, before it must become a formal role or stop?
- Who checks on it before the end date, and how is it either ended or turned into a proper role? (Defining the new role is a Role Registry question.)
Examples
Every temporary task is given with an end date or a clear "done when" condition and logged as temporary on the task board by whoever assigns it. A week before it ends, the assigner and the person doing it check in: the task either ends, or it is proposed as a new role for the Role Registry. No temporary responsibility may run longer than 90 days in total, extensions included.
Examples, not recommendations. Your answers will be your own.
Role and Domain Interfaces
Where does one role's work end and the next one's begin?
RCOS clauses 7.6.3, 7.3.4
Why map handoffs explicitly?
Most operational failures happen not inside a role but between roles — at the boundaries where work moves from one owner to the next. Naming the handoffs turns invisible dependencies into reviewable ones, and prevents "I thought you had it" failures.
How to fill this in
For each pair of roles that pass work to each other, name the handoff and the type of work transferred.
| From | To | Handoff |
|---|---|---|
| <role> | <role> | <what is handed off> |
| <role> | <role> | <...> |
What to cover
- Which roles regularly pass work to each other?
- For each handoff: what is handed over, in which direction, and how does the receiving role know it has arrived?
- At what point does the work stop being the first role's responsibility and become the next one's?
- Where does work pass between a role and a meeting — for example, a decision that a role must then carry out?
- When a handoff gets dropped, who notices and who sorts it out?
Examples
Membership Admin to Infrastructure Steward: when a new member's trial starts, the admin posts their details in the access channel and the steward sets up accounts within three days; on exit the same route removes them. Finance Steward to Contribution Steward: at each month-end the finance steward shares amounts paid in so contribution records can be reconciled. Governance meeting to role holders: each adopted decision is assigned to a named role in the notes, and that role confirms it has picked it up.
Examples, not recommendations. Your answers will be your own.
Workload Boundaries
How much time, meeting and care can we ask of one person — and what happens when someone is overloaded?
RCOS clauses 7.4.1, 7.4.2, 7.4.3, 7.4.4, 7.7.3
- 7.4.1 Time, attention, coordination capacity, and emotional labor MUST be treated as finite and limited resources.
- 7.4.2 The community MUST define explicit workload boundaries, including:
- 7.4.3 Workload boundaries MUST be reviewable and adjustable through an authorized governance process.
- 7.4.4 Persistent overload, burnout risk, chronic non-participation, or dependency on over-functioning individuals MUST trigger review or repair processes as defined in Layer 4.
- 7.7.3 Meeting load, coordination burden, and unpaid or invisible labor MUST be bounded and reviewable.
Why make workload limits explicit?
Unbounded coordination load is the default failure mode of volunteer communities — it quietly burns out the most committed members until they leave. Explicit, reviewable limits make capacity a shared concern rather than a private burden.
How to fill this in
Set bounds on meeting load, role load, response-time expectations, and the path for renegotiating responsibilities.
- Meeting load: <recurring meeting cadence and maximum duration; rules for extraordinary meetings.>
- Role load: <cap if any; rule for flagging overload; resolution window.>
- Response time expectations: <non-urgent async; urgent operational; safety-critical.>
- Renegotiation and relief: <process for redistributing responsibilities; resolution window.>
- Persistent overload: <how persistent overload, burnout risk, chronic non-participation, or dependency on over-functioning individuals is detected, and how it is routed into the Layer 4 review or repair process.>
What to cover
- How much meeting time can we ask of one person — how often, how long, and what counts as an extra meeting?
- How many roles or hours a week may one person carry — counting unseen work like hosting, cleaning up or emotional support?
- What reply times do we expect — for everyday messages, urgent operational matters and safety issues — and when is nobody expected to answer?
- When someone says they are overloaded, how is their work covered, handed on or shared out — and how quickly?
- What signs tell us there is a pattern — lasting overload, burnout, members going quiet, or everything resting on a few people — and which review or repair process does that start?
- How often do we review these limits, and how are they changed?
Examples
Recurring meetings take up at most four hours a month per person; an extra meeting needs 72 hours' notice. Nobody holds more than two roles or about eight hours a week, care and hosting work included. Messages get a reply within three days, urgent operational ones within a day, safety issues at once. Anyone can say they are overloaded, and their tasks are reshared within two weeks; overload flagged twice in a quarter goes to our review-and-repair process. These limits are reviewed yearly and changed by proposal.
Examples, not recommendations. Your answers will be your own.
Operational Continuity
If any one of us disappeared for a month, what would stop working?
RCOS clauses 7.5.1, 7.5.2, 7.5.3
Why plan for continuity now?
A community that depends on one irreplaceable person is one illness, one conflict, or one exit away from collapse. Naming the single points of failure — honestly — and building handover into every role is what keeps the community surviving its founders.
How to fill this in
Name current single points of failure honestly. State the handover requirement for each role and the cadence of continuity review.
- Current state: <honest list of single points of failure; recruitment plan to reduce concentration.>
- Handover mechanisms: <reference handover requirements per role in the Role Registry; handover must be completed before a role is vacated.>
- Continuity review cadence: <quarterly; ad hoc on role change.>
What to cover
- Honestly, who or what is a single point of failure today — a person, account, key or skill that only one of us has?
- For each one: what is our plan to share it, and by when?
- For each core role and process: is the procedure written down, and what must be handed over before the holder leaves?
- Who backs up each core role — and where is a backup not yet possible?
- How often do we review this, and what else triggers a review, such as a role changing hands?
Examples
Today only one member can access the bank account and only one understands the water system. By March a second bank signatory will be added, and the water system will have a written guide and a trained deputy. Every core role has a named backup and a handover checklist that must be completed before the holder steps down. The Infrastructure Steward reviews this list every quarter and whenever a role changes hands.
Examples, not recommendations. Your answers will be your own.
Information Flow and Anti-Gatekeeping
How do we make sure nobody has to go through one person to find something out?
RCOS clauses 7.3.5, 7.7.4, 7.3.2
Why treat information access as a governance issue?
Whoever controls access to information controls the community, whether they mean to or not. Making access rules explicit — and disallowing sole points of access — is what prevents informal gatekeepers from accumulating the kind of power the governance system is supposed to check.
How to fill this in
State which records are open to all Full Members, the response window for information requests, and the rule against sole points of access for governance-relevant information.
- <Governance decisions accessible to all Full Members.>
- <Meeting notes published within X hours.>
- <Membership state and role assignments accessible.>
- <Contribution records accessible.>
- <Information request response window.>
- <Withholding access to information members are entitled to is an accountability trigger under Layer 4.>
- <No role or individual may be the sole point of access for information required by other role holders.>
What to cover
- Which records can every Full Member open directly, without asking anyone — decisions, meeting notes, roles, membership, contributions? (Restricted and private records are their own question.)
- How soon after a meeting must notes and decisions be published?
- When someone asks for information they are entitled to, who must answer, and within how long?
- How do we make sure no single person or role is the only way in to information others need — passwords, files, contacts?
- What happens when someone holds back information a member is entitled to?
Examples
Every Full Member can read decisions, meeting notes, role assignments, membership status and contribution records in the shared drive without asking anyone. Meeting notes are posted within 48 hours. Any other request for information a member is entitled to is answered within five days. Every shared account and folder has at least two people with access, and withholding information a member is entitled to is treated as an accountability issue under our conflict process.
Examples, not recommendations. Your answers will be your own.
Documentation Locations and Update Procedures
What do we write down, where, and who may read it — and can every decision be traced to who made it and how?
RCOS clauses 7.3.1, 7.3.2, 7.3.3, 7.8.1
Why name where every document lives?
If no one can say where the canonical version of something lives, there is no canonical version. Naming the location, owner, and review cadence for each document type is what makes the community's memory auditable rather than folkloric.
How to fill this in
For each document type, name the canonical location, the owner, and the review cadence.
| Document type | Location | Owner | Review cadence |
|---|---|---|---|
| <RCOS artifacts> | <location> | <owner> | <cadence> |
| <Member registry> | <location> | <owner> | <cadence> |
| <Meeting notes> | <location> | <owner> | <cadence> |
| <Governance proposals> | <location> | <owner> | <cadence> |
| <Contribution records> | <location> | <owner> | <cadence> |
What to cover
- For each kind of record — our governance documents, member registry, meeting notes, proposals, contribution records: where does the official copy live, who keeps it, and how often is it reviewed?
- What must be written down about decisions, roles, day-to-day operations and shared obligations — what does each record have to contain at minimum?
- Who may read which records, and which are restricted for privacy — on what grounds, and who may still see them?
- When must a new record be published or announced, and to whom?
- Does every decision record say what type of decision it was and which area it covers, who had the authority, how it was decided and by what threshold, the outcome, and when it takes effect?
- Where can anyone find, written down, our roles, who may decide what, our meeting types, and our access and privacy rules?
Examples
Governance documents, the member registry and proposals live in the shared drive, kept by the Secretary and reviewed yearly; meeting notes and contribution records live on the wiki, kept by each facilitator and the Contribution Steward and reviewed quarterly. Every decision record states its type and area, who decided, the mechanism and threshold, the outcome and its start date, and is announced within three days. Members can read everything except health, safeguarding and conflict records, which only the people involved and two named stewards may see.
Examples, not recommendations. Your answers will be your own.
Ratification Record
- Adopted: <YYYY-MM-DD>
- Decision type: Strategic
- Version: <version>
- Decision record: <link to decision record>