Most shuls choose a management system roughly once a decade, usually after a demo, usually under time pressure because the current arrangement has just failed in some visible way. Then they live inside that choice for years: every member record, every Gift Aid claim, every event, every website page.
This is a checklist for that decision. It is written from the UK synagogue side rather than the vendor side, and it includes the questions that are least comfortable to ask.
1. Start from the joins, not the features
Every system will show you a membership list, an invoice and an event page. They all have those. What differs is whether the parts are genuinely one system or several products behind one login.
The test is to trace a single real scenario end to end. For example:
A member pays £360 for a dinner for two and adds a £100 donation. They have a Gift Aid declaration on file. They also move house next week.
Ask the vendor to show you, on screen: the event registration, the payment, the £100 arriving as a donation against that member's record, the Gift Aid applying only to the eligible £100, the receipt, and then the address change appearing everywhere without being typed twice. If any step involves an export, a re-import, or “you would just also update it here”, you have found a join. Joins are where the admin time goes and where the mistakes live.
2. Ask what happens to your data, before you ask about features
Three questions, in this order:
- Can we export everything ourselves, at any time, without asking you?Not “can you send us an export”. Self-service, on demand, in a format that opens in Excel. A vendor who controls the exit controls the renewal conversation.
- Who is the data controller? Under UK GDPR it should be the shul, with the software provider acting as processor on your instructions. Get this in writing, because it determines who answers a subject access request and who is liable if something goes wrong.
- Where is the data held, and who can see it?UK or EU hosting, and a clear answer on which of the vendor's staff can read your member records and under what circumstances.
A shul's membership list contains addresses, family relationships, dates of birth, yahrzeits and financial history for a community that has good historical reasons to care about who holds lists of its members. Treat it accordingly.
3. Understand how the price behaves as you grow
Pricing models are not neutral. Per-member pricing means the shul pays more precisely when it succeeds at the thing it exists to do, and it creates a quiet incentive to keep lapsed members off the system, which corrupts the membership list, which was the point of the software.
Work out the three-year cost, not the monthly headline, and specifically ask:
- What does the price do if we go from 120 members to 200?
- Are there per-transaction fees on donations and subscriptions, on top of the card fees?
- Which features are on a higher tier, and which are separately chargeable add-ons?
- What is the setup or onboarding fee, and what does it actually cover?
- What is the contract length and the notice period?
Payment processing deserves its own line of questioning. Ask whether the money goes directly to the shul's own merchant account or passes through the vendor first. Directly is what you want: it is faster, it is clearer for the accounts, and it means a dispute with the software vendor cannot become a dispute about your income.
4. Test it on the Jewish calendar, not on a generic month
This is where software written for churches or for general charities usually reveals itself. The vocabulary can be swapped easily; the structure cannot. Ask to see:
- Yahrzeits stored by Hebrew date and reminding on the right English date each year, not a fixed anniversary that drifts.
- Davening times derived from zmanim and rules, so the week generates itself, rather than a table someone retypes each Thursday night.
- Shabbat and Yom Tov understood by the system, including that automated emails and payment reminders should not be landing on them.
- Honours and aliyot recorded, and where relevant linked to what was pledged and whether it was invoiced.
- High Holidays, the annual spike in seating, appeals and event capacity that a generic system meets with a spreadsheet.
5. Get Gift Aid demonstrated, not described
“We support Gift Aid” covers everything from a full claim pipeline to a checkbox on a donation record. Ask to see the claim schedule the system produces and compare it to what HMRC actually wants. Then ask the follow-ups:
- Are declarations captured and stored with the evidence HMRC expects, including the date?
- Does a declaration apply automatically to future eligible donations, or does someone tick a box each time?
- Is Gift Aid calculated on the gross donation or on the net after card fees?
- How does it handle membership subscriptions, where eligibility depends on what the member receives in return?
That third question separates the serious systems from the rest. We go through it properly in the Gift Aid guide for shul treasurers.
6. Judge it as software a volunteer will run
The person entering next year's membership subscriptions is a trustee with a full-time job, doing this on a Sunday evening. That is the actual user. Two practical checks:
- Ask for a trial account and have the least technical person on your committee attempt one real task unaided: add a family, raise an invoice, send a message. Watch without helping.
- Ask how long onboarding takes and who does the data migration. If the answer requires you to clean the data first, ask what “clean” means, because your data is what it is.
7. Ask about the exit before you sign the entry
Specifically:
- If we leave, what happens to our website and to any public links we have shared?
- Do our members' saved payment methods and Direct Debit mandates move, or do we have to re-collect them?
- How long is our data retained after we go, and how do we have it deleted?
Re-collecting standing orders from a whole community is the single most expensive thing on that list. It is worth knowing the answer before you need it.
A one-page summary
- Trace one real scenario end to end and count the joins.
- Self-service export, shul as data controller, UK/EU hosting.
- Three-year cost, not monthly headline. Watch per-member pricing.
- Money goes to the shul's own account, not via the vendor.
- Hebrew dates, zmanim, yahrzeits and honours as structure, not labels.
- Gift Aid demonstrated to claim-ready output, including the fee treatment.
- A volunteer completes a real task unaided in the trial.
- Exit terms understood before signature.
If you want to see how one system answers all of these, this is how Kehilla is put together. The trial is 45 days with no card, which is deliberately long enough to run a real billing cycle through it before you commit to anything.