See it working: Beth Knesset is a real demo shul on the platform. Website, calendar, donations and lobby TV. Take the guided tour →
Built for synagogues

Your shul's website, office and email, in one place.

Build and run your website from the portal. Manage members, pledges, payments, sponsorships and events in one ledger. Email the whole community and see who visits your site. Every payment lands on the right account the moment it is made, and every surface carries your shul's name, not ours.

Beth Knesset is a working demo shul you can browse right now. No signup, no sales call first.

1,000+Contacts per congregation
<1sTypical portal load
0Card numbers we store
0Of our branding on your site

Four jobs, one system

What used to take a website builder, a membership database, a payment processor and Mailchimp, sharing one set of records.

Don't take our word for it

Walk around Beth Knesset, our demo shul

A complete congregation website connected to a real portal. Click any page, sponsor a kiddush with a test card, and watch it come off the calendar.

Take the guided tour Open the demo site →

Test card 4111 1111 1111 1111, any future expiry, any CVV. Nothing is charged.

The shul office runs on three systems that disagree

A membership spreadsheet. A payment processor. A website somebody built years ago. Every month somebody reconciles them by hand — and every month a payment goes missing.

Website payments vanish

Someone donates $180 on the shul website. It hits the processor. It never reaches their account. The office finds out when that member is billed for money they already paid.

Pledges live in someone's head

An aliyah is pledged on Shabbat, written on a card, typed in on Tuesday — if it gets typed in at all. Nobody can answer "what do I owe?" without three phone calls.

The website is frozen

Prayer times changed, but the site says otherwise, because updating it means emailing the volunteer who has the password. So it stays wrong.

The one that costs you money

Every website payment finds its account. Automatically.

This is the failure we hear about most, and it is the thing this platform was built around. Your website and your portal are not two systems talking over an integration — they are one system with two front doors. A payment made on the public site is written straight into the same ledger the office works in.

Someone pays on your site

Donation, kiddush sponsorship or an event ticket — no login needed.

→

It lands in the ledger

Same database as the office. Not an export, not a nightly sync.

→

It attaches to a person

Known payer: instantly. Stranger: one click, and their whole history follows.

If we already know them

Anyone paying from a statement link or logged into their account is identified before a card is ever charged. The payment is written against their record with the pledge it settles, and their balance moves the same second.

  • Emailed invoice links are cryptographically signed — they identify the payer, and cannot be edited to point at somebody else
  • Payments pay down the oldest pledge first, automatically, and split across several if the amount covers them
  • A part-payment leaves the correct remainder — no all-or-nothing

If we don't

A stranger's payment is recorded with the name, email and phone they typed, and flagged in the office as unattached. One click turns it into a contact — and retroactively adopts every other unattached payment that used the same email.

  • Shows you a preview first — how many payments, totalling how much — before anything is written
  • Matches on email only: a phone is often shared across a household, and mis-linking money is worse than under-linking
  • Never moves a payment already attributed to someone else
  • If a contact already uses that email it refuses and points you at them, so you merge instead of creating a duplicate
See exactly how it works

One system, for everything the office actually does

Not a CRM you have to bend into a synagogue shape. Built around aliyot, kiddush sponsorships, High Holiday seats and yahrzeits from the first line of code.

Contacts & members

Households, spouses, children, yahrzeits and aliases. Membership tiers separate from plain contacts, so a donor is not accidentally a member.

Pledges & payments

Every aliyah, every kiddush, every membership fee. Pledges and their charges stay in lockstep, and payments allocate oldest-first without anyone doing arithmetic.

Kiddush & Seuda

Open a date at a price you set; a member books it from their phone or the public site. Slots are held atomically, so two people cannot take the same Shabbat.

Events & seats

Ticketed events with member and non-member pricing, adults and children counted separately, optional capacity caps, and High Holiday seats priced by tier.

Statements & receipts

A branded statement any member can pull themselves, a running balance they can follow, and an emailed receipt for every payment — with an opt-out.

Your public website

Pages you build by clicking, a menu you drag into shape, prayer times and events that stay current, and visitor numbers in the portal.

Seating

Draw each section's rows and seats, then assign permanent seats or seats for one event, by person within a household.

Store & sign-ups

Members buy tickets, seats and items inside the portal at their member price. Events can ask sign-up questions and export the answers.

Lobby TV screen

Hebrew date, parasha, prayer times, events and announcements on the TV in the lobby, updating itself.

Everything the platform does →
Make it yours

It should look like it was built for your shul

Not a product with your logo dropped in a corner. Your members open the portal and the website and see your congregation's own system — because as far as they are concerned, that is exactly what it is. Two shuls running on this platform can share not one pixel.

  • No vendor branding anywhere. No "powered by" badge, no watermark in a footer, no logo of ours on a statement, a receipt or an invitation
  • Your colours and logo carry everywhere — the portal, the public website and every email you send. Not one page: all of them
  • Your login page is yours. It works out the congregation from the web address and themes itself before anyone types a password
  • Your words. Pledge types, honours, membership tiers and payment methods, all named the way your community says them out loud
  • Your own domain, so nothing in the address bar belongs to us either
How far the personalisation goes →
bethknesset.shulservices.com
The Beth Knesset demo congregation site in emerald and gold with a classical serif wordmark — a wholly different visual identity from the Shul Services brand.

Beth Knesset chose emerald, gold and a classical serif. Nothing on the page — or in their portal, or on their statements — announces the platform underneath. That is the point.

It is a real accounting system, and it runs your calendar

Two things a shul office is asked for constantly, and the two most people are surprised to find in the same place.

🧾

A double-sided ledger

Charges on one side, payments on the other, netting to a balance you can defend to a treasurer or an auditor. Every figure traces back to the row that produced it, and every row is stamped with who touched it.

See the ledger →
📅

An event on sale in four steps

Create it, drop in a flyer, attach the tickets and their prices, save. It is on your website with a working checkout immediately — no developer, no deploy, and every purchase lands on the buyer's account.

See the steps →
📄

Statements on demand

Members download their own full history — every pledge, payment and donation, with a running balance — as a spreadsheet or a branded statement, any time, without asking the office for anything.

See what they get →
Security

You are holding other people's money and details

A shul database is a list of who belongs to your community, what they give and how to reach them. It deserves better than a shared spreadsheet on somebody's laptop.

  • We never see a card number. Card details go straight from the payer's browser to the processor; we hold only the last four digits and the brand
  • Two-factor is mandatory for administrators — an authenticator code, every session
  • Every congregation is sealed off. Each request is authorised against that congregation specifically; a request for another shul's data is refused outright
  • Every change is signed. Who created it, who changed it, who cancelled it, and in what role

Read the full security posture →

Card data never touches us

Tokenisation happens in the payer's browser. The card number never reaches our servers, so it cannot leak from them.

Checked twice at the door

Every request is verified at the gateway and again inside the application. A mistake in one is caught by the other.

Nothing is really deleted

Records are cancelled, not destroyed. A year later you can still answer what happened, when, and who did it.

See it with your own congregation's numbers

Send us a membership list and a year of transactions. We will load them into a private demo and walk you through your own shul, not a fictional one.