Cleric Standard Operating Procedure

A Cleric is the client relationship lead for a Raid. The Cleric helps turn a qualified opportunity into a well-formed engagement, keeps commercial and client expectations clear during delivery, and coordinates a complete closeout.

This SOP applies the shared Raid Lifecycle. The CRM is the source of truth for the opportunity and commercial next action. Discord is the coordination surface. Portal holds durable project context. The Prism Raid Agent's dedicated channel is the primary interface for Clerics to maintain CRM and Portal records; direct use of either product UI is available when needed but is not the default workflow. The responsible Treasury role and tooling hold the financial record.

Responsibilities

The Cleric:

• owns or clearly coordinates the client relationship;
• confirms the client's need, desired outcome, budget context, timeline, and decision process;
• keeps the CRM opportunity accurate or ensures its assigned owner does;
• assembles the prospective Raid Party with a Monk and the required builders;
• coordinates scope, proposal, contract, payment schedule, and party split;
• keeps the client informed and raises risks early;
• ensures, usually through the Raid Agent, that the Portal project represents active work accurately;
• coordinates with the Treasury role without duplicating financial records in Portal or Discord; and
• completes the relationship, documentation, payment, and archive handoffs.

On a small Raid, one person may serve as both Cleric and Monk. Name both sets of responsibilities explicitly so client management and delivery management are not lost between roles.

1. Accept the Handoff

Opportunities may begin with a web submission, a Hunter's relationship, a meeting, a referral, email, a direct message, or another channel. Not every opportunity needs a Discord channel.

Before taking responsibility:

1. Search the CRM for the person, account, lead, or opportunity to avoid duplicates.
2. Confirm the opportunity has an owner, source, useful summary, and next action.
3. Clarify the handoff with the Hunter, including relationship history and any promises already made.
4. Record yourself as the Cleric or otherwise make the client relationship owner unambiguous.

Web intake notifications arrive through #client-submissions in the Agency area. A submission notification is not a complete CRM record and does not automatically require a Raid channel.

2. Qualify the Engagement

Meet with the client or coordinate with the Hunter to understand:

• the problem and desired outcome;
• the people affected and the decision maker;
• the likely services and skills required;
• budget context and expected timing;
• constraints, dependencies, and material risks; and
• the next decision or action needed to move forward.

Use the dedicated Raid Agent channel to capture factual findings and the next action in the CRM. A Cleric may edit the CRM directly when needed.

There is no standard consultation fee. If paid discovery or scoping is appropriate, treat it as an explicitly scoped engagement with agreed deliverables and commercial terms.

3. Open the Internal Coordination Space

Create a channel in the Raids category when the qualified opportunity needs ongoing internal coordination among several Guild members. A Raid channel is internal and member-only.

At the top of the channel, make it easy to find:

• the client and opportunity summary;
• the Cleric and Hunter;
• the proposed Monk and party, when known;
• the current lifecycle stage and next action;
• links to the CRM opportunity and working documents; and
• the Portal project, contract, or external communication links when they exist and the audience is appropriate.

Do not put client-facing communication in the internal Raid channel.

4. Choose the Client Communication Surface

Use the communication surface that fits the relationship:

• create a Camp when a shared Discord channel is convenient;
• use email when that is the client's normal workflow; or
• use the client's own platform when required.

A Camp is optional and client-visible. Keep candid internal coordination in the Raid. Do not assume that the Raid Agent can read a Camp; client-shared access requires an approved confidentiality and permissions policy.

5. Assemble the Party and Scope the Work

Recruit through #who-is-available and direct outreach when appropriate. Work with the Monk and prospective party to define:

• desired outcomes and deliverables;
• scope boundaries and assumptions;
• roles, responsibilities, and decision rights;
• milestones, timeline, and dependencies;
• budget and payment schedule;
• risks and change-management expectations; and
• the proposed compensation split.

Keep commercial status and the next action in the CRM. Keep working detail in the Raid and the party's chosen project documents. A Portal project is optional during scoping and should be created early only when a concrete collaboration surface already exists.

6. Formalize the Engagement

Before delivery begins:

1. Confirm the scope, milestones, acceptance expectations, and client responsibilities in writing.
2. Confirm the contract and payment schedule through the approved legal and Treasury processes.
3. Record the agreed party split, including the mandatory 10% Guild spoils.
4. Confirm that paid contributors have completed the current RaidGuild DAO LLC and payment requirements.
5. Decide whether escrow reduces risk for this engagement. Smart Invoice may be used, but escrow is not mandatory.
6. Update the CRM opportunity and next action.

Never rely on Discord messages alone as the financial record. Payment instructions, wallet or banking details, distributions, and transaction evidence belong in the approved Treasury workflow.

7. Begin Delivery

When the engagement is authorized to start:

1. Confirm the Monk and party responsibilities.
2. Confirm the client and internal communication cadence.
3. Ask the Raid Agent to create or update the Portal project, link it to the CRM opportunity and Raid channel, and return a preview or change summary for review.
4. Confirm where scope, decisions, deliverables, risks, and change requests will be documented.
5. Update the CRM to reflect that delivery is active.

Portal is the durable project context and presentation layer. It is not the commercial pipeline, the Raid's task manager, or the Treasury record. Clerics normally maintain that context through the Raid Agent rather than manually operating the Portal UI.

Before approving a new Portal project, confirm the title and summary, linked opportunity, project state, people, relevant links, source evidence, and intended visibility. Public narrative, case-study language, and visibility changes always require human review. See Rendering a Project in Portal for the full handoff.

8. Maintain the Client Relationship

During delivery, the Cleric:

• gives the client clear updates at the agreed cadence;
• works with the Monk to surface scope, timeline, budget, and delivery risks early;
• records commercial changes and next actions in the CRM;
• keeps Portal context accurate without exposing confidential or financial information;
• coordinates invoices and payment status with the responsible Treasury role; and
• confirms that changes to scope, staffing, timing, or compensation are agreed and documented.

The Raid Agent is the primary interface for routine CRM and Portal updates. It may review permitted Raid activity and propose or apply clear, factual, non-sensitive updates within its approved permissions. Conflicts, uncertain matches, sensitive changes, and public publishing decisions return to the dedicated Raid Agent channel for human review.

9. Close the Raid

When delivery concludes:

1. Confirm acceptance of the final deliverables and identify any transition or support obligations.
2. Coordinate final invoicing, payment, distributions, and 10% Guild spoils with the responsible Treasury role.
3. Confirm the CRM opportunity has the correct outcome, close reason when relevant, and final relationship next step.
4. Ask the Raid Agent to mark the Portal project completed when that status is supported; until then, have it record the completion date and current state.
5. Hold a retrospective when useful and preserve durable lessons without exposing client-confidential information.
6. Prepare or update a case study when appropriate and obtain the necessary client and publishing approval.
7. Move inactive Raid and Camp channels to Valhalla according to the current archive practice.

If an engagement ends early, record it as Cancelled rather than Completed, resolve outstanding contractual and Treasury obligations, and document the client handoff.

Suggested Party Split

The party may use this historical split as a starting point:

Recipient	Suggested share
Guild spoils	10% mandatory
Hunter	5%
Cleric	10%
Monk	15%
Project team	60%

Only the 10% Guild spoils is fixed here. The remaining split is a suggestion and should reflect the actual responsibilities, effort, risk, and agreement of the party. Record the final split before delivery and update it explicitly if the engagement changes.

Cleric Closeout Checklist

• The client knows the final outcome and any remaining obligations.
• The CRM status, summary, and next action are current.
• The Raid Agent's Portal preview or change summary has been reviewed, and the project shows the correct completion context and visibility.
• Final payment, party distributions, and Guild spoils are confirmed through Treasury.
• Confidential records remain in their approved systems.
• The retrospective and case-study decision are recorded.
• Raid and Camp channels are archived when no longer active.