{"id":3220,"date":"2026-09-28T08:23:39","date_gmt":"2026-09-28T12:23:39","guid":{"rendered":"https:\/\/myshul.com\/software\/?post_type=seo_article&p=3220"},"modified":"2026-09-28T08:30:03","modified_gmt":"2026-09-28T12:30:03","slug":"synagogue-crm","status":"publish","type":"seo_article","link":"https:\/\/myshul.com\/software\/articles\/synagogue-crm\/","title":{"rendered":"Synagogue CRM: One Record Per Person, and Who Sees It"},"content":{"rendered":"

A synagogue CRM is one record per person connected to the shul, the relationships between those people, and the history of everything the office has done with them. That history is dues charged and paid, donations and pledges, event registrations, form submissions, yahrzeit and Hebrew birthday dates. The term comes from sales software, where CRM means customer relationship management, and it sits awkwardly on a shul, where the "customer" is a member whose connection to the building may be three generations old.<\/p>\n

That is why no two vendors mean the same thing by it. One publishes a synagogue CRM page that is really a feature list, another avoids the term and says "member database," a third borrows the vocabulary of marketing automation and writes about conversion funnels, which is not how a shul office thinks. Underneath the labels the question is small and answerable: what does the system hold about a person, how does it connect that person to everyone else, and who is allowed to see it.<\/p>\n

This is one layer of a larger stack. The buyer’s guide to synagogue management software<\/a> covers the billing, scheduling, events and accounting above it.<\/p>\n

A Synagogue CRM Answers Questions a List Cannot<\/h2>\n

Strip away the terminology and the office wants three things. One authoritative record per person, so nobody has to work out which of four spreadsheets is current. The history of dues, gifts and attendance hanging off that person rather than filed by year. And an answer when you put a question to it: who hasn’t renewed, who has a yahrzeit next month, who still owes on last year’s dinner.<\/p>\n

A list of names and email addresses does the first job and only the first. That is the line most shuls are trying to cross, and worth knowing which side a vendor sells.<\/p>\n

Synagogue CRM vs. Donor CRM vs. General Nonprofit Software<\/h2>\n

Three kinds of product get sold into this job, and they are built for different work.<\/p>\n

A donor CRM<\/strong> is built for fundraising. The record is a constituent, and the tools around it are appeals, campaigns and lifetime giving totals. It does that well, and a shul that runs on it ends up with dues, seating, sponsorships and yahrzeits bolted on as afterthoughts.<\/p>\n

General-purpose nonprofit or membership software<\/strong> gets closer. It understands joining, renewing and lapsing. What it does not have is the shul’s own workflow: zmanim calculated for the building, a minyan schedule that reflows when the times move, aliyah and honors billing, kiddush sponsorships, High Holiday seating, and Hebrew-calendar dates that drive a reminder instead of sitting in a text field.<\/p>\n

A synagogue CRM<\/strong> is the record plus that suite of features, built for how a shul office works. MyShul is built that way: the same record that holds a member’s dues and family links drives the schedule, the sponsorship slots, the seating chart and the yahrzeit email. That is the whole difference the category needs to make.<\/p>\n

One Record Per Person, and the Family Around It<\/h2>\n

Everything downstream reads off this record: the bill, the statement, the reminder, the list. Worth being fussy about an unglamorous screen. In MyShul it carries the membership tier and its price, enrollment and expiration dates, auto-renew, payment status, whether the member is in good standing, and custom fields for what a particular shul tracks. Members log in with a code sent by text or email to see their own invoices, transactions and memberships, and enter their own dates. The sibling article on what the member record must hold<\/a> goes field by field.<\/p>\n

Relationships are the part vendors describe worst. Ask how a family shows up in the record and on the statement, and settle it with any vendor early, not during the first billing run.<\/p>\n

Hebrew-calendar dates sit on the record the same way, with members entering their own. MyShul converts the civil date to the Hebrew date with nightfall taken into account and emails the yahrzeit reminder<\/a> ten days ahead. Ask any vendor who receives that reminder: a date held against one person is not the same as a date a whole family hears about.<\/p>\n

Your Database Is Not Your Directory<\/h2>\n

Keep these straight and a phone number a member gave the office for billing never turns up in front of the membership. The database is the internal record: balances, tiers, history. A directory is a curated, member-facing view of part of it. Most coverage treats them as one thing.<\/p>\n

Before buying, ask four questions: is there a member-facing directory at all, which fields appear in it, can a member hide a field or opt out entirely, and where does it appear \u2014 in the member app, on the website, or both. Vendors answer differently, and the answers rarely appear on a feature page.<\/p>\n

Who Gets to See What<\/h2>\n

A volunteer entering donations for a week should see donations for a week. That is the internal half of privacy, and a shul office is staffed by people with different reasons to be in the system: a bookkeeper, a part-time administrator, a gabbai who maintains the yahrzeit list, that volunteer.<\/p>\n

MyShul handles it with role-based permissions. An administrator grants a non-admin user specific areas \u2014 invoicing, schedules, reports \u2014 or a broader management role, with certain pages blocked even at that level. A user can hold more than one role at once, and a role can be revoked the day a volunteer’s term ends.<\/p>\n

The practical test is granular against binary. "Admin or not admin" hands that volunteer the entire membership roll and every balance in it, which nobody decided.<\/p>\n

Pull the List Without Opening a Spreadsheet<\/h2>\n

Good records earn their keep the day a list comes out of the system, not somebody’s memory. The lists a shul office needs are specific: everyone whose membership lapsed this year, every family with a yahrzeit this month, everyone with an open balance, last year’s kiddush sponsors.<\/p>\n

Two things decide whether that works. The first is whether the data was ever there to filter on, which loops back to the member record. The second is what happens at the end of the list. Email to members and to lists is built into MyShul, so the office is not exporting addresses into a separate mail tool, and the same records drive dues and invoicing<\/a>: batch billing, statements, and accounts receivable aging when the board asks who owes what.<\/p>\n

Ask for the List in Plain English<\/h2>\n

MyShul also offers AI-assisted member search: an administrator describes the list in plain English and gets it back, which saves working out which filters produce the list already in your head.<\/p>\n

A plain-English query runs against the record, so the fields the office tracks are what it can find. That is one more reason to get the database right first.<\/p>\n

What to Check Before You Switch<\/h2>\n

Seven questions, tied to the sections above.<\/p>\n