Motivation: a CRM for Life Itself / Second Renaissance

This records the original CRM motivation and nine job stories. Twenty has since been adopted and imports, forms and course delivery have shipped; the proposed evaluation steps below are historical.

Moved here from life-itself/crm motivation.md on 2026-10-09, to keep the what and why with the Comms Infrastructure project. To be consolidated with comms use cases later. Use the README job-story scorecard for current implementation evidence and Beads epic crm-dxb for next work (agent handoff). Broader publishing/provisioning requirements are in comms use cases.

SCQH

Situation

People connect with Life Itself / 2R through many doors: newsletter (Substack), courses, events (Luma, Tito), manifesto signatures, retreats, hub residencies, research projects, direct correspondence. Each door captures a name and email — into that tool's silo, a spreadsheet, or nowhere at all.

Concrete example: 27 emails just arrived from Teal Estate relating to the Developmental Spaces project. There is nowhere to put them that records who they are, where they came from, and what they signed up for.

Known pools waiting to be consolidated (from comms#187):

• DS manifesto signatories
• DDS research retreat (Sep) attendees
• DDS steering group
• DDS 2023 interviewees and launch call invitees
• Cohere+ collaborators
• Berlin / Bergerac / London hub residents
• Previous team members and collaborators
• Teal Estate devspaces list (27 emails)

Complication

• No single place to look up a person and see their history (newsletter reader, course participant, event attendee, funder, collaborator).
• No way to segment: "everyone who might care about this new course / white paper" is unanswerable today.
• Data decays in tool silos; each new project re-collects contacts from scratch.
• Team is very small: any workflow requiring manual data entry or manual imports will not happen. Capture must be automated.
• Related infra (email sending, sequences, forms) is being shaped separately in comms#163; we must not conflate the CRM layer with the whole stack, but the CRM must interface cleanly with it.

Question

What contact/relationship store should we adopt — and what capture and use workflows around it — so that every signup, attendee, and correspondent flows automatically into one queryable place we actually use?

Hypothesis

Adopt a dedicated CRM layer (candidate: Twenty, open source, API-first, self-hostable) whose job is strictly: store people, their sources/tags, and their interaction history; make them queryable and exportable. Capture is automated via APIs/webhooks/Gmail sync, not manual entry. Email sending, forms, and automation remain separate systems (per #163) that read from / write to the CRM via API.

The workflow (capture → store → use)

Even though we only implement the CRM layer now, the workflow defines its shape:

CAPTURE (automated)                STORE                    USE
Luma event signup      ─┐
Tito ticket purchase   ─┤   Person record:            Segment + export list
Substack subscriber    ─┤   - email, name             → email campaign
Google Form response   ─┼→  - sources/tags        →   Person lookup (360 view)
Website form           ─┤   - interactions            Relationship notes,
Gmail correspondence   ─┤   - notes, owner            follow-ups
CSV batch (legacy)     ─┘

Design consequences:

1. Every contact carries provenance: source (which door), date, and context (which project/event). Without this, segmentation is impossible.
2. Interactions are records, not overwrites: a person can attend three events and take two courses; each is a row linked to the person.
3. Capture is push-based and automated: webhooks or small sync scripts per source. If a source can't push, a scheduled script pulls. Manual import is a one-time migration path only.
4. Use is mostly query + export: the CRM doesn't send bulk email; it produces the audience list for whatever sends it.

Job stories

Capture

1. When someone signs up for an event on Luma or buys a ticket on Tito, I want them to appear in the CRM automatically tagged with that event, so the list is building itself without anyone doing data entry.
2. When someone fills in a Google Form or website signup form (e.g. the devspaces interest form), I want their response to create/update a CRM record with the form as source, so form data stops dying in spreadsheets.
3. When I correspond with someone by email, I want that correspondence linked to their CRM record automatically (mailbox sync), so I can see relationship history without logging anything.
4. When I receive a legacy list (e.g. the 27 Teal Estate emails), I want to import it once with a source tag, so historical pools get consolidated.

Use — segment + outreach

5. When we launch a new course, I want to pull "everyone who took a related course, attended a related event, or signed up for related topics", so we announce to a warm audience instead of only the general newsletter.
6. When we publish a white paper, I want to email everyone who attended events for previous white papers or signed the manifesto, so research outputs reach the people who showed interest.
7. When exporting a segment, I want a clean CSV / API feed into our email tool, so outreach doesn't require re-keying.

Use — relationship management

8. When I'm about to meet a funder or collaborator, I want to look them up and see every touchpoint (events, courses, emails, notes), so I arrive with context.
9. When a promising contact appears, I want to add a note and a follow-up owner, so warm relationships don't silently go cold.

Evaluating Twenty

Against the questions in comms#187 (sources: Twenty docs):

The three ❌s are all things we've decided the CRM layer should not do — so they're not disqualifiers.

Open questions to verify hands-on:

• Model check: can we represent "person attended event X" / "signed up via source Y" cleanly (custom object vs tags vs relations)? How well does segmentation/filtering work across those?
• Gmail sync with multiple team mailboxes — behaviour, privacy controls (per-user sync, internal emails excluded by default).
• Luma/Tito/Substack → Twenty: what's the actual integration path (native? Zapier? small scripts hitting the REST API)?
• Self-host effort vs $9/user/mo cloud — who maintains it?
• Export path to email tool chosen in #163.

Proposed next steps

1. Spin up Twenty (cloud trial or local Docker) and model the schema: Person, Source tag, Interaction/Event participation.
2. Import the Teal Estate 27 + one other pool (e.g. DS manifesto signatories) as a real test.
3. Prototype one automated capture: Luma → Twenty via API script or webhook.
4. Test one real segment query + export ("everyone connected to devspaces").
5. Report back into comms#187 / #163 and decide adopt vs alternatives.