Skip to content

CRM

[HYPOTHESIS]No CRM is selected or deployed. This section documents the plan: why Big Nerd Idea needs a CRM, the evaluation in progress, and the data-care principles any chosen tool must satisfy before it touches real records. Everything described as "configuration" or "setup" is planned, not done.

Purpose

A CRM (customer/constituent relationship manager) would give BNI one disciplined place to manage the relationships the organization actually runs on:

  • Funders & grants — LOI → application → award → deliverable lifecycle, deadlines, funder contacts.
  • Partners — makerspaces, recovery centers, reentry programs, schools, libraries, senior centers; MOU status and named points of contact.
  • Donors — individual and corporate (including IT-equipment donors for Second Boot / Boot Up), one-time and recurring contributions, and tax-receipt handling once 501(c)(3) status exists.
  • Program participants — enrolled cohort members from vulnerable populations (recovery, reentry, formerly incarcerated, elderly): attendance, module completion, device awards, follow-up.

These four needs span the Foundation and the LLC and every project. Today they live in scattered Markdown notes and spreadsheets. A CRM is the proposed consolidation — if the data-care bar below can be met.

Program-specific funder and partner records are not duplicated here. The live, working lists belong to the program that owns them:

This CRM section is about the tooling and data-handling discipline, not the relationship data itself.

[HYPOTHESIS] The evaluation compared Twenty and CiviCRM against ten criteria, with Airtable / spreadsheet-as-CRM as a deferral option. The honest reading:

  • CiviCRM is the better out-of-box fit for BNI's stated "all of the above" needs — donor + contribution tracking, a grants module, and 20+ years of mature, documented nonprofit-PII patterns. Its cost is the UX is dated and the stack is PHP (off BNI's TypeScript-first practice).
  • Twenty fits the stack and has the better UX, but treats donations/grants as custom build-out and lacks established nonprofit-PII patterns — which the data-care bar below treats as a real risk, not a cosmetic one.
  • For a 2-person, pre-pilot, pre-501(c)(3) org, the strongest counter-recommendation is to defer the real-CRM decision: keep funders/partners/grants in Airtable and participants in a separate restricted base, and revisit once a determination letter, a first cohort, and the first grant applications have produced the data that would justify the complexity.

None of these is decided. The evaluation lists the gates (sample-data import, PII walkthrough, tax-receipt round-trip, backup/restore drill, two-person fit test) that must pass before any commitment.

Data care comes first

Because BNI's participants include vulnerable populations, the participant-data design is the gating concern, not an afterthought. A pleasant UI or stack fit does not override it. Before any real participant record is entered into any tool, the data-handling design must clear the bar set out in data-security.md — PII minimization, role-based access, retention limits, and the heightened care owed to data about people with no margin for harm. Those safeguards are planned and unverified ([HYPOTHESIS], pending [EXPERT REVIEWED]); this section does not claim they exist yet.

In this section

  • Evaluation — Twenty vs. CiviCRM, decision criteria, honest recommendation, and the defer option.
  • Data security & PII handling — planned safeguards and the vulnerable-user data-care bar.

Known unknowns

  • Which tool (if any) BNI will adopt — undecided.
  • Whether to defer the decision entirely until post-501(c)(3) — open.
  • Whether any candidate tool's PII controls actually satisfy BNI's care bar — untested; needs [EXPERT REVIEWED].
  • Self-host vs. managed hosting, and who owns CRM administration on a 2-person team.