Part of Synagogue Management Software: What to Buy, and Why
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.
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.
This is one layer of a larger stack. The buyer’s guide to synagogue management software covers the billing, scheduling, events and accounting above it.
A Synagogue CRM Answers Questions a List Cannot
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.
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.
Synagogue CRM vs. Donor CRM vs. General Nonprofit Software
Three kinds of product get sold into this job, and they are built for different work.
A donor CRM 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.
General-purpose nonprofit or membership software 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.
A synagogue CRM 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.
One Record Per Person, and the Family Around It
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 goes field by field.
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.
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 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.
Your Database Is Not Your Directory
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.
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 — in the member app, on the website, or both. Vendors answer differently, and the answers rarely appear on a feature page.
Who Gets to See What
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.
MyShul handles it with role-based permissions. An administrator grants a non-admin user specific areas — invoicing, schedules, reports — 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.
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.
Pull the List Without Opening a Spreadsheet
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.
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: batch billing, statements, and accounts receivable aging when the board asks who owes what.
Ask for the List in Plain English
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.
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.
What to Check Before You Switch
Seven questions, tied to the sections above.
- How families are modeled. Ask how a family appears in the record, and what that does to the bill.
- Custom fields. Whether the shul can add what it tracks without a support ticket.
- Permission granularity. Named areas a volunteer can be given, not an admin switch.
- Directory visibility. What members see about each other, and what they can hide.
- List building. Whether staff can pull a segment without exporting to a spreadsheet.
- What comes in and what comes out. MyShul imports contacts from CSV, your data can be exported, and statements and receipts go out automatically by email with a PDF attached. Confirm with any vendor that records can be exported any time the office needs them.
- Who does the migration. MyShul does its own, moving members, balances, transaction and payment history, yahrzeits and family relationships, and shuls are up and running quickly.
None of these show up in a feature grid. All of them show up twenty minutes into a demo.
Bring Your Own Awkward Cases
The demo worth having is the one where you hand over your own hard cases: the family with three billing arrangements, the yahrzeit after nightfall, the volunteer who needs exactly one screen. To see how MyShul handles yours, book a demo.
Frequently asked questions
What is a synagogue CRM?
The database underneath everything else the office does: one record per person connected to the shul, the relationships between those people, and the history of what the office has done with them — dues charged and paid, donations and pledges, event registrations, form submissions, Hebrew-calendar dates. In most shuls it is not a separate product from the membership system. It is the record layer under it.
How is a synagogue CRM different from a donor CRM?
A donor CRM is built for fundraising: constituents, appeals, campaigns and giving history. A synagogue CRM holds the same record but surrounds it with the shul's own workflow: dues and statements, zmanim and the minyan schedule, aliyah and honors billing, kiddush sponsorships, High Holiday seating, and yahrzeit reminders driven by the Hebrew calendar. MyShul is built around that workflow, so the office runs from one record instead of a donor tool with add-ons.
Do we need a separate CRM if we already have synagogue membership software?
Usually not, because in most shuls they are the same product. The question worth asking is not whether a vendor uses the word CRM, but whether one record holds the member's dues status, family links, custom fields and Hebrew dates together, and whether staff can pull a list from it without exporting to a spreadsheet first.
Can members control what other people see about them?
That depends entirely on the vendor, so ask rather than assume. Ask whether there is a member-facing directory at all, which fields it shows, whether a member can opt out or hide a phone number, and whether staff permissions are separate from what members see.
Can we move our membership spreadsheet into a synagogue CRM?
Yes, and it is routine: CSV import of an existing contact list is standard, and MyShul imports contacts from CSV. For a full switch from another platform, MyShul does the migration itself, including balances, transaction and payment history, yahrzeits and family relationships, and shuls are up and running quickly.
