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

A website your office can build and run itself

A page builder, a menu editor, prayer times and events that stay current, payments that land in the ledger, a slideshow for the lobby TV and a count of who visits. All of it from the Website tab in the portal, with no developer and no second password.

Page builder

Build a page by clicking it

Every page on your site is made of sections you can see and click. Pick one, change the words, swap the picture, point the button somewhere else and press Publish.

  • Sections you write: banner, text, picture with text, feature cards, call to action, gallery, buttons and dividers
  • Sections the portal fills for you: prayer times, classes, upcoming events and holidays, always current because they read the same records the office edits
  • Buttons that do things: open a page, start a donation to a named fund, sell an event's tickets, open the sponsorship calendar or the member login
  • New pages in a minute. "Our rabbi", "Membership", "Bar mitzvah guide": add the page, build it, put it in the menu
  • Two languages if your community needs them. A page and its menu tab can each carry an English and a French version
  • Publish, or go back. Reset returns the whole site to the last version you published, so experimenting is safe
See a site built this way →

Drawn from the portal's Website › Pages tab, with Beth Knesset's home page open.

Website analytics

See who visits, and what they click

The Website tab counts your own traffic: how many people came, which pages they read, which buttons they pressed and where they came from. No Google Analytics to set up, and no cookie banner to add.

  • Visitors, page views, visits and clicks for the last 7, 30 or 90 days, each compared with the period before
  • Top pages, so you know whether people come for the schedule or the events
  • The buttons people press: Donate, Buy tickets, Sponsor a kiddush, call the office
  • Where visitors come from (search, Facebook, WhatsApp, typed in) and what they use: phone, tablet or computer
  • The busiest hours of the day, so you know when the Friday crowd checks candle lighting

Counted without following anyone

No cookies and no tracking pixels. A visit is counted for the day and nothing that identifies a person is kept, so there is nothing to disclose and nothing to leak.

Drawn from the portal's Website › Analytics tab. The numbers are illustrative.

bethknesset.shulservices.com/tvscreen
Beth Knesset's lobby TV screen: the Hebrew date and parasha at the top, a clock, upcoming event cards on the left, a featured event in the middle and the week's prayer times on the right.

Beth Knesset's lobby screen: Hebrew date, parasha, clock, events and prayer times. Open it live →

Lobby TV screen

The TV in the lobby, kept up to date for you

Point any TV with a browser at your site's TV page and leave it. It shows the Hebrew date, the parasha, the time, today's prayer times, upcoming events and holidays, your announcements and a rolling photo collage.

  • Announcements with pictures, written in the portal's TV Screen tab
  • You choose what rotates and for how long, and which prayer times stay pinned beside it
  • It refreshes itself through the day and reloads every night, so nobody has to touch the TV

Why website payments normally go missing

On most shul websites the donate button belongs to the payment processor, not to the shul's records. The money arrives. The attribution does not.

The usual arrangement

A payment button on the website posts to Stripe, PayPal or a donation widget. That system knows an email address and an amount. It does not know your member numbers, your pledges, or that this $180 was meant for the Kol Nidre appeal.

  • Somebody exports a CSV at month end
  • Somebody matches names by eye and types them into the membership system
  • Anything ambiguous goes in a "sort out later" pile that is never sorted out
  • A member gets billed for money they already paid, and rings the office upset

How this works instead

The website has no payment system of its own. It writes to the same ledger the office works in, through an API built for exactly this. The payment is a transaction on your books from the instant it is approved.

  • No export, no CSV, no nightly sync, nothing to reconcile
  • Known payer → attached to their record immediately, against the right pledge
  • Unknown payer → recorded with their details and flagged, ready to attach in one click
  • The office sees it in the Transactions tab within seconds of the card clearing

Public website

Donation, sponsorship or ticket — no login required

→

Public API

Its own isolated service. Prices recomputed server-side.

→

Your ledger

The same transactions the office manages, attributed to a person

Two ways a payment finds its owner

They arrived from something you sent them

A statement email, an invoice, a "you owe $360" reminder. The link in it carries a signature that identifies the member — so before a card is even shown, the system knows exactly whose account this is. They pick what they want to pay, and it is applied to those pledges, oldest first.

The signature cannot be tampered with to point at a different member, expires after 30 days, and is confirmed against their phone number before any balance is displayed.

They came to the website cold

A congregant's cousin donates $118 for a yahrzeit. A guest buys two Shabbaton tickets. Nobody logged in, and the office has never heard of them. The payment is recorded with the name, email and phone they entered, and shows in the Transactions tab flagged as unattached.

One click opens a preview: "This will create a contact and attach 4 transactions totalling $412." Confirm, and it happens.

🔗

It adopts the back catalogue

Attaching a guest does not just claim today's payment — it sweeps up every earlier unattached payment that used the same email, so their whole history arrives at once.

📧

Email only, on purpose

Matching is done on email and never on phone. A phone number is often shared across a household, and attaching money to the wrong person is worse than leaving it unattached.

🛑

It refuses to make a mess

A payment already attributed to someone is never moved. And if a contact already uses that email, it stops and points you at them — so you merge rather than create a duplicate.

Content

Edit it once, in the portal

There is a Website tab in the portal. What you type there is what the public sees — no separate CMS, no second password, no volunteer to email.

  • Prayer times: weekday, Shabbat, Rosh Chodesh. A time can follow the sun ("sunset minus 20, rounded to 5 minutes") and update itself every week
  • Classes and shiurim with times and teachers
  • Events, each with a flyer, its own web address, an Add to calendar button and an optional sign-up form. Past events stay in an archive
  • Private events that sell only through a link you send, and early-bird prices that switch off on the date you set
  • Holidays and the yom tov schedule, with Hebrew dates and the parasha on every calendar
  • Photo gallery albums, shown on the site and on the lobby TV
  • Seat and sponsorship pricing, which is the same pricing the checkout uses
  • Your logo, uploaded once, appearing on the site, the portal and your emails

The prices on the site are the prices in the system

They are not typed in twice. A ticket price changed in Settings is changed on the website and at the checkout at the same moment, because there is only one of it.

bethknesset.shulservices.com/schedule
The Beth Knesset demo website prayer schedule page, showing a table of weekday services with days and times.

Prayer times on the demo congregation's site, served live from the portal — change them in Settings and this page changes.

bethknesset.shulservices.com/sponsor
The Beth Knesset demo website kiddush sponsorship page, showing a September 2026 calendar with Kiddush and Seuda buttons on available Saturdays and a legend for available versus reserved.

Genuinely open dates, worked out on the server at the moment the page loads.

Taking money safely

A calendar that cannot be double-booked

Selling from a public page is where most systems get into trouble. Two people open the same Shabbat; both pay; one gets a refund and an apology.

  • Availability is computed on the server, not trusted from the browser
  • The slot is reserved before the card is charged, with a write that fails if anyone got there first
  • If the card is declined, the hold is released — no phantom bookings left behind
  • Every payment carries an idempotency key, so a double-click or a retried request cannot charge twice
  • The amount is always recalculated from your settings; whatever the browser claims the price is, is ignored
  • No sponsor's name is ever exposed by the public API — it says taken, not who
Architecture

Shared database, separate front doors

The decision that makes all of this work — and the one that keeps it safe. Your website and your portal share the data. They do not share the way in.

The portal's API

Everything the office and your members use. Every request carries a signed token and is checked twice before it reaches any data.

  • Logins, roles, contacts, full financial history
  • Rejected at the gateway if the token is missing or wrong
  • Never reachable from the public website

The public API

A separate service with a deliberately tiny surface. It is the only thing an anonymous visitor can reach, and it cannot read a member record.

  • Reads only whitelisted content — no personal data, ever
  • Writes only donations, sponsorships and ticket purchases
  • Geo-restricted, rate-limited and challenge-protected

Why this matters more than it sounds

The usual shortcut is to let the website call the same API the portal uses, with a shared key embedded in the page. Anyone who views source then holds that key. Here, the anonymous website is architecturally incapable of reading a member's details or anyone's balance, because the service it talks to has no code that can do it.

None of it looks like our software

Your congregation is not a tenant number in somebody's SaaS. Every surface a member or a visitor sees carries your name, your colours and your words — set by your office, in a Branding tab, without involving us.

🎨

Your colours

A primary, a secondary and an accent colour, set in Settings. They are not decoration on one page — they propagate.

  • The member portal
  • Your public website
  • Every email you send — statements, receipts, invitations
🖼️

Your logo

Uploaded once in the portal, and it appears everywhere it should — including the browser tab icon.

  • Portal header and login screen
  • Website header and favicon
  • The top of every emailed statement
✍️

Your name, everywhere

A display name and a legal name, used in the right places rather than one name jammed into all of them.

  • The name emails arrive from
  • The legal name on receipts and statements
  • Even the label in an administrator's authenticator app

Your members never see a login page that isn't yours

The sign-in screen works out which congregation it belongs to from the web address and themes itself before anyone types anything. A member arriving at your portal sees your logo and your colours on the very first screen — not ours, and not a generic one that changes once they are through.

The same platform does not have to look the same

Two congregations on this platform can share not one pixel. Below is our demo shul, Beth Knesset, which chose emerald and gold with a classical serif — nothing about it announces the software underneath.

What you choose

  • The whole visual language — palette, typography, photography, the shape of the header
  • Which pages exist. A small shul may want four; an established one wants schedule, classes, rabbi, membership, holidays, donate and sponsor. Add more yourself in the page builder
  • Your own domain, with the certificate handled for you
  • Your words. "Contacts" or "Members", "Aliyot" or "Honours", Sephardi or Ashkenazi spellings — the wording follows your community, not our defaults

What your office controls day to day

  • Pledge types — every aliyah and honour, named the way your gabbai says them out loud
  • Membership tiers and what each costs
  • Payment methods, including the ones only your shul uses
  • Products and prices for tickets, seats and sponsorships — which is why adding a High Holiday seat class is a settings change, not a phone call to us
  • Occasions, kiddush tiers, seat classes — all yours, all editable, no ticket raised
bethknesset.shulservices.com
The Beth Knesset demo congregation website, styled in emerald green and gold with a serif wordmark — a completely different visual identity from the Shul Services brand.

Beth Knesset's own identity — emerald and gold, classical serif, its own photography. Same platform as every other congregation on it.

Nothing here is our branding

There is no "powered by" badge, no watermark in the footer and no logo of ours on your statements. Your members deal with your shul.

What connecting a website actually involves

Whether we build it or you already have one.

You already have a website you like

It keeps its design. We add the pieces that need to be live — a schedule that reads from the portal, a donate page, a sponsorship calendar, an events list — and point them at your congregation's content. Everything else on your site stays exactly as it is.

You want us to build it

You get a complete site: home, schedule, classes, events, holidays, donate, sponsor and contact. Your colours, your logo, your photographs. Every content page is wired to the portal from day one, so it is never out of date.

Either way, the hosting is handled

Your own domain with a certificate that renews itself, served from a global CDN, on storage that is not publicly reachable. Clean addresses without .html on the end. Nothing for you to patch, renew or remember.

Typically live within two weeks of us having your content and domain access.

Stop reconciling the donate button

Bring us your current site and your last month of website payments. We will show you where each one would have landed.