Document begins
Runbook: Intake, Membership, and Volunteer Coordination
Portfolio issue #37. Internal use only. Not for public release. Maintained by: Intake Coordinator (to be named at the 23 May working group selection meeting)
What this runbook is for
This is the step-by-step operating guide for the intake coordinator role. It covers how to run the weekly triage cycle, generate the coverage report, draft follow-up messages, and manage the consent and privacy obligations that attach to EOI data.
The matching spec (private/agents/portfolios/intake-membership-coordination.md) describes what the portfolio does and which agents are assigned. This runbook describes how a human coordinator does the work, including the exact commands to run, the prompts to use, and the approval gates to respect.
Standing obligations (always on)
- No outbound contact without approved template. No message reaches a respondent until the template has been marked
[APPROVED]by the convenor. Drafts are drafts until that flag is present. - No data sharing beyond the intake coordinator. Triage lists, raw submissions, and follow-up queues stay inside the Access-protected admin vault or this
internal/directory. Do not paste into Slack, email, or a shared Google doc. - No commitment language. Nothing in any outbound message may imply membership, a co-op share, financial return, or a confirmed role. Stage 1 language only: “we’re exploring whether this is worth pursuing.”
- Consent flag is a gate. The only hard exclusion is
consent = 'no-contact'— that is an explicit refusal.NULLmeans the person submitted but did not tick any consent box; since they chose to submit the form, treat them as contactable for general follow-up but not for skills-specific outreach (same asupdates-only). The form stores consent as a comma-joined list of opt-in values, e.g.updates, skills-contact, or the override valueno-contact. For skills follow-up, the relevant gate isconsent LIKE '%skills-contact%'.
Periodic tasks
| Frequency | Task |
|---|---|
| Weekly (Monday) | Run triage query; update triage list |
| Weekly (Monday) | Flag stale submissions (>30 days, no follow-up note) |
| Before any outbound send | Run coverage report; confirm template is approved |
| After working group meeting | Update eoi-role-matrix.md gap-role status |
| On request | Generate onboarding brief for a confirmed participant |
Part 1 — Weekly coverage report
What it tells you
Which gap roles have at least one candidate, which are unfilled, and whether any “Now”-urgency role is still uncovered.
Step 1.1 — Pull the raw submission counts
Run this in your terminal (requires wrangler installed and authenticated):
wrangler d1 execute bottompub-eoi \
--command="
SELECT
skills AS skill_bucket,
capacity AS capacity_tier,
COUNT(*) AS total,
SUM(CASE WHEN consent != 'no-contact' OR consent IS NULL THEN 1 ELSE 0 END) AS contactable,
SUM(CASE WHEN consent LIKE '%skills-contact%' THEN 1 ELSE 0 END) AS skills_contactable
FROM submissions
GROUP BY skills, capacity
ORDER BY skills, capacity
" \
--remote
Copy the output table. You will paste it into the coverage prompt below.
Step 1.2 — Pull the stale submissions list
wrangler d1 execute bottompub-eoi \
--command="
SELECT
id,
submitted_at,
name,
skills,
capacity,
consent
FROM submissions
WHERE (consent != 'no-contact' OR consent IS NULL)
AND submitted_at < date('now', '-30 days')
ORDER BY submitted_at ASC
" \
--remote
This list is for your reference only. Do not distribute it.
Step 1.3 — Generate the coverage report (Claude prompt)
Open a new Claude conversation. Paste the following prompt, filling in [PASTE RAW COUNTS HERE] with the output from Step 1.1.
Coverage Report Prompt
You are the intake coordinator for the Bottom Pub Co-op feasibility project, currently at Stage 1 (gauging interest only — no membership offer, no financial commitment, no confirmed structure).
Below is the raw submission count from the EOI database, grouped by skill bucket and capacity tier.
[PASTE RAW COUNTS HERE]
Using the role matrix below, produce a coverage report table with the following columns:
- Gap role (from the matrix)
- Urgency (Now / Soon / Later)
- Candidate skill bucket(s) that could cover it
- `skills_contactable` count at working-group or subgroup capacity (these are people who have consented to a skills conversation)
- `contactable` count at any capacity (everyone except explicit no-contact, including updates-only and NULL — useful for gauging general interest but not for skills follow-up)
- Status: Covered / Partial / Unfilled
Role matrix (excerpt — full matrix is in internal/eoi-role-matrix.md):
- Operations / Governance → Urgency: Now
- Legal → Urgency: Now
- Communications / Marketing / Media / Design → Urgency: Now
- Volunteer coordination / onboarding → Urgency: Now
- Membership admin / CRM → Urgency: Now
- Data / web / privacy → Urgency: Now
- Research synthesis / evidence management → Urgency: Now
- Building / Trades → Urgency: Soon
- Hospitality → Urgency: Soon
- Finance → Urgency: Soon
- Community Development → Urgency: Soon
- Grants / fundraising → Urgency: Soon
- Accessibility / inclusion / safeguarding → Urgency: Soon
- Insurance / risk / compliance → Urgency: Soon
- Heritage / conservation liaison → Urgency: Soon
Rules:
- "Covered" requires at least one `skills_contactable` candidate at working-group or subgroup capacity who maps to the gap role.
- "Partial" means `skills_contactable` candidates exist but only at lower capacity tiers, OR there are `contactable` candidates in the bucket but none who have opted into skills follow-up.
- "Unfilled" means no `contactable` candidates at all in a matching bucket.
- Do not mark a role "Covered" just because a candidate exists — they must be at a capacity tier that could actually hold that function.
- Do not use commitment language. This is a planning tool, not a membership list.
After the table, add a short paragraph (3–4 sentences) summarising the most critical gaps for the intake coordinator to raise at the next working group meeting.
Step 1.4 — Save the report
Save the output as internal/coverage-report-YYYY-MM-DD.md. Do not commit it to git — it contains aggregate EOI data. Keep it in internal/ for the duration of Stage 1.
Part 2 — Weekly triage list
What it tells you
Each consented respondent’s suggested capacity tier and recommended next step, so the intake coordinator knows who needs follow-up and in what order.
Step 2.1 — Pull the triage data
wrangler d1 execute bottompub-eoi \
--command="
SELECT
id,
submitted_at,
name,
skills,
capacity,
skills_detail,
interest_level,
thoughts,
consent
FROM submissions
WHERE consent != 'no-contact' OR consent IS NULL
ORDER BY submitted_at DESC
" \
--remote
Step 2.2 — Run the triage prompt (Claude)
Open a new Claude conversation. Paste the following, replacing [PASTE SUBMISSION ROWS HERE].
Triage Prompt
You are the intake coordinator for the Bottom Pub Co-op feasibility project, Stage 1 (gauging interest only).
Below are consented EOI submissions. For each respondent, produce a triage row with:
- Respondent ID (the `id` field)
- Self-declared capacity tier (from the `capacity` field)
- Recommended ladder tier (from the contribution ladder below)
- Best-fit stream or gap role (from the role matrix)
- Recommended next step (one of: Draft follow-up / Await further interest / Flag for convenor review)
- Any flag (e.g. "stale — submitted >30 days ago", "capacity mismatch — declared subgroup but skills suggest advisory", "commitment language in free-text — review before contact")
[PASTE SUBMISSION ROWS HERE]
Contribution ladder tiers (in descending capacity):
1. Working-group seat — holds a named stream, fortnightly meetings, 6–12 month commitment
2. Subgroup participant — owns a bounded task cluster within a stream
3. Few hours per week — task-lead or ops-support, bounded repeatable work
4. Few hours per month — specialist advisory, called on as needed
5. Member-only — receives updates, votes, attends open events
6. Just learning — on the mailing list, no commitment yet
Rules:
- Do not recommend a higher tier than the person declared unless their skills clearly justify it AND note the mismatch.
- Do not use their name in the output column where I haven't asked for it — use ID only.
- Flag any free-text that contains commitment language (e.g. "my share", "when I'm a member", "expecting a return") so those submissions can be reviewed before any contact.
- This list is for the intake coordinator's use only. Do not produce anything that reads like a communication to the respondent.
Step 2.3 — Save and review
Save as internal/triage-YYYY-MM-DD.md. Review the flags before any follow-up action. Any Flag for convenor review items go to the convenor before a draft message is written.
Part 3 — Follow-up message drafts
When to draft
Only after:
- The triage list is complete and reviewed
- The coverage report shows at least one gap role where follow-up would be useful
- The convenor is aware of the intent to draft
Step 3.1 — Identify the tier(s) to draft for
From the triage list, identify which capacity tier(s) have respondents who are ready for a next-step message. Typical first run: working-group seat candidates in “Now”-urgency roles.
Step 3.2 — Draft prompt (Claude)
Follow-up Draft Prompt (Working-Group Seat Tier)
You are drafting a follow-up message to people who expressed interest in joining the Bottom Pub Co-op feasibility working group. This is Stage 1 only — we are gauging interest, not offering membership, shares, or any financial return.
Write one plain-text email template for respondents at the working-group seat capacity tier who have skills in [INSERT STREAM NAME — e.g. "Legal" or "Operations / Governance"].
The message must:
- Thank them for their EOI
- Explain that we are forming a small working group to assess feasibility
- Describe what a working-group seat involves (fortnightly meetings, stream ownership, 6–12 month Stage 1 commitment)
- Invite them to a brief conversation or to confirm their interest
- Include a clear opt-out line ("If your circumstances have changed, just let us know and we'll remove you from the follow-up list")
- Be warm but not salesy
The message must NOT:
- Imply they are already a member or will become one
- Mention shares, financial return, dividends, or investment
- State that the property is available or that the owner has agreed to sell
- Promise any outcome ("this will happen", "we will open", "you will receive")
- Sound like a marketing email
Tone: direct, collegial, community-oriented. Length: 150–200 words. Subject line: something honest, not clickbait.
After the template, add a short note (2–3 sentences) flagging any phrase in the draft that the human reviewer should check for stage-discipline compliance before approving.
Step 3.3 — Human approval gate
Print or paste the draft into a document titled follow-up-template-[tier]-[stream]-DRAFT.md. Send to the convenor. The template is not approved until the convenor marks it [APPROVED — [name] — [date]] in writing.
Do not send, queue, or reference this template in any outbound system until that mark is present.
Step 3.4 — Personalise and queue
Once approved, personalise for each respondent in the triage list using their name and stream. Do not add any information beyond what the template contains. Queue in your email client for manual send — do not use a bulk-send tool unless that tool has been approved for this purpose.
Part 4 — Privacy and consent housekeeping
What you hold
The submissions table contains: name, contact method, interest level, thoughts (free text), skills, capacity, skills detail, submission date, and consent flag.
There is no email column in submissions — contact method is a free-text field that may contain an email, phone number, or other identifier. Handle it as personally identifiable information regardless.
Monthly privacy check
Run this to confirm no unconsented submissions are in the active triage pool:
wrangler d1 execute bottompub-eoi \
--command="
SELECT COUNT(*) AS explicit_no_contact
FROM submissions
WHERE consent = 'no-contact'
" \
--remote
If the count is non-zero, those submissions may be counted in aggregate statistics only. They must not appear in triage lists with identifying fields.
Removal requests
If a respondent asks to be removed:
- Note the request in
internal/privacy-log.md(create if it does not exist): date, submission ID, method of request. - Run:
wrangler d1 execute bottompub-eoi \ --command="DELETE FROM submissions WHERE id = [ID]" \ --remote - Confirm deletion with a second query:
SELECT id FROM submissions WHERE id = [ID]— should return no rows. - Reply to the requester confirming removal. Use plain language: “We’ve removed your submission from our records.”
Do not retain a copy of the removed record anywhere (not in triage lists, not in coverage reports named with their ID).
Part 5 — Onboarding handoff
When a respondent moves from intake to confirmed working-group participant (requires convenor sign-off):
Step 5.1 — Generate the handoff brief (Claude)
You are preparing an onboarding brief for a stream lead to hand to a new working-group participant.
The participant's details (from the triage list):
- ID: [ID]
- Skill bucket: [SKILLS]
- Capacity tier: [CAPACITY]
- Stream assignment: [STREAM NAME]
Write a one-page brief that includes:
1. What the stream does and why it matters at Stage 1
2. What the participant is expected to own (task or stream, depending on tier)
3. Who they report to or check in with
4. The three most important things to know before their first meeting
5. Where to find the key documents (just filenames — do not paste internal content into this brief)
Tone: practical and welcoming. This is a working brief, not a marketing document.
Step 5.2 — Save and route
Save as internal/onboarding-[ID]-[stream]-[date].md. Send to the relevant stream lead (not the participant directly — the stream lead does the actual welcome).
Part 6 — Lower-tier holding messages
Respondents who are triaged into subgroup, few-hours, member-only, or just-learning tiers are not invited into a core working-group seat. They still deserve a reply. This part documents the holding-message procedure for each tier.
When to send
Send a holding message after each weekly triage cycle, for any respondent who has been assigned a tier below working-group seat AND has not yet received any outbound contact. Do not send before the triage list is reviewed and no Flag for convenor review items are outstanding.
All templates in this part require the same human-approval gate as Part 3: convenor marks the template [APPROVED — [name] — [date]] before any send.
Template A — Subgroup / Few-hours tier
Use for respondents whose triage recommendation is “Subgroup participant” or “Few hours per week.” These people offered specific help; they should know they have not been forgotten.
Subject: Your interest in the Bottom Pub co-op — a quick update
Hi [first name],
Thank you for your EOI. We've noted your interest in [skill area].
We're currently forming the core working group. Your details are in our intake list for the subgroup and task-support tier — which means we'll be in touch if a matching task opens up that fits your skills and availability.
In the meantime, you'll receive periodic project updates by email.
If your circumstances or interest have changed, just let us know and we'll update your record accordingly.
[Sender name]
Bottom Pub Co-op feasibility project
Stage 1 — Gauging Interest only
Approval gate: save as internal/follow-up-template-subgroup-DRAFT.md, send to convenor.
Template B — Member-only tier
Use for respondents whose triage recommendation is “Member-only (supporter / turnout / feedback).”
Subject: You're on the list — Bottom Pub co-op updates
Hi [first name],
Thank you for your expression of interest. You're now on our mailing list for project updates.
We'll keep you informed as the feasibility work progresses. There are no commitments at this stage — this is still an open question about whether a community-owned pub is worth pursuing.
You'll hear from us when there's something worth sharing. If you'd like to be removed from the list at any time, just reply to this email and we'll take care of it.
[Sender name]
Bottom Pub Co-op feasibility project
Stage 1 — Gauging Interest only
Approval gate: save as internal/follow-up-template-member-only-DRAFT.md, send to convenor.
Template C — Just-learning tier
Use for respondents whose triage recommendation is “Just learning” — people who are curious but have not indicated a specific role or capacity.
Subject: Thanks for your interest — Bottom Pub co-op
Hi [first name],
Thanks for filling in the form. It's good to know you're following the project.
We won't ask anything of you right now. Our job at Stage 1 is to share enough information for people to make a real decision about whether to get involved, and at what level.
You're on our mailing list and will receive updates as the work progresses. If that ever changes and you'd like to play a more active role, just get in touch.
[Sender name]
Bottom Pub Co-op feasibility project
Stage 1 — Gauging Interest only
Approval gate: save as internal/follow-up-template-just-learning-DRAFT.md, send to convenor.
Mailing-list placement
After sending any holding message, confirm the respondent’s email address (from the contact_method field) is subscribed to the project mailing list. This is the ongoing channel for all respondents not in an active follow-up lane.
Mailing list as primary owned channel — open decision. Whether the email list is the primary owned channel for project updates (vs. one channel among several) has not been formally decided. This decision is on the working-group agenda. Until ratified, treat the mailing list as the default holding channel for all non-core-seat respondents and do not make public claims about its status.
Failure modes and what to do
| Situation | What to do |
|---|---|
| A message was sent without an approved template | Halt all further sends. Notify the convenor immediately. Document what was sent, to whom, and when. |
| A triage list was shared with someone outside the intake coordinator role | Escalate to the convenor. Document the incident in internal/privacy-log.md. |
| A draft follow-up contains commitment language | Do not approve or send. Rewrite using the prompt in Part 3. Flag the specific phrase so it is not re-introduced. |
| A coverage report marks a gap role “Covered” but the candidate has not confirmed | Correct to “Candidate identified — unconfirmed.” Only move to “Covered” after the stream lead has had a conversation and the convenor has noted the assignment. |
| A respondent asks what their data is used for | Send them internal/privacy-notice.md verbatim. Do not paraphrase — the notice is the approved response. |
| The D1 database is inaccessible | Do not attempt to reconstruct the list from memory, email, or other sources. Contact the technical coordinator. Do not proceed with triage until access is restored. |
Contacts and access
- Convenor: [to be named at working group selection meeting]
- Technical coordinator (D1 / wrangler access): [to be named]
- Admin vault access: Cloudflare Access —
bottom.pub/admin/* - D1 database name:
bottompub-eoi - Wrangler authentication: run
wrangler loginif your session has expired
Last updated: 2026-05-22. Review at the start of each stage transition.