Church & Congregation Event Registration

The vertical decides the vocabulary, the questions asked at checkout, the inventory model, the door, the payout terms and the theme. This page says "place" and "event" because that is what a church says; a config whose primary call to action is generic ticketing wording fails validation rather than shipping.

Who this is not for. Excludes regular worship services, which are not ticketed. If that is closer to your operation, the vertical you want is probably a different one — all twenty are listed here.

The sign-up sheet at the back of church, and the four names nobody can read

A paper list tells you nothing until the week of the event, and what it does tell you is wrong. Somebody writes "the Nolans x4" and means five, somebody adds a name on a Sunday you were away, two people sign up twice because the first sheet went missing, and the caterer wants a number on Wednesday. The cost is not the admin. It is food for sixty when forty-two arrive, and a family turned away from a hall that had room in it.

What bindro does: Places are counted inventory here rather than lines on a page. Each event has a fixed pool of places, what is left is live while sign-ups are open, and the number in the office is the same number the person signing up is looking at. You get a page of your own to link from the pew sheet and the weekly email, or the same checkout embedded in the church website, and neither of them can sell the sixty-first place in a sixty-place hall — inventory moves only under a row lock inside the transaction that takes the money, with a database constraint behind that.

Charging enough to cover the event prices out the people you most want there

A retreat that costs the church $45.00 a head is either $45.00 a head, which quietly excludes a family that cannot say so, or free, which the budget cannot carry twice a year. Most churches land on an envelope and a quiet word, and the quiet word is the part that fails: the household who cannot pay is exactly the household least likely to ask, and they simply do not come.

What bindro does: Publish a band and a suggested amount, and let each household choose inside it. You set a floor and a ceiling on the place — nothing to fifty dollars, say — and a suggested figure the form fills in by default. Anything outside the band is refused on the money path with the band named, so what you are paid is always a number you published. A household that chooses your floor signs up exactly as everyone else does, and the door works from a name list, not a price list: nobody standing at the entrance can see what anyone chose.

The consent form for the youth trip comes back on the morning, or not at all

Paper consent is a chase. It goes home in a bag, comes back signed by whoever was nearest the pen, and the ones that never come back are discovered in the church car park with a minibus running. Meanwhile the booking was taken weeks ago by an adult who ticked a box on behalf of a parent they may not have spoken to, which is not consent and would not be treated as consent by anyone who had to defend it.

What bindro does: The guardian signs it themselves, from their own email, and the door refuses the child until they have. When a place is marked as being for someone under 18 the form asks for the guardian's own address, and the countersign request is raised in the same transaction that takes the money — so it exists for exactly the bookings that went through. Until it is signed that child is left off the offline door list and a check-in against them is refused. Waivers for a work party or a walking trip work the same way: the signer's name, the exact wording shown and a digest of that wording are stored, so next year you can still tell which version each household agreed to.

The hall has no signal and the door is two volunteers with a printout

Church halls are thick-walled, half-basement and behind the church, and the building's wifi reaches the office and stops. A door tool that needs a connection turns arrival — the twenty minutes when a hundred and twenty people arrive at once with children and casserole dishes — into a volunteer scrolling a spreadsheet that is still loading. So most churches print the list, and then the printout and the system disagree for the rest of the evening.

What bindro does: The door device downloads the list before the event and works with no connection at all. Congregations check in by name rather than by scanning a code, so the manifest carries the names the door actually needs and nothing else — no prices, no giving, no allergy answers. Check-ins made offline replay when the device gets signal, replaying twice counts once, and if two volunteers on two phones tick the same person off it surfaces in a conflict list instead of one of them silently winning. A QR code is there for the churches that want one, but nothing depends on a person having found their email.

The rota is a WhatsApp thread, and the church database is open to everyone in it

Volunteer scheduling by group chat means nobody is quite sure who is on the door at four, two people bring the same tray and the person who dropped out told one member of a thread of nineteen. The other half of the problem is worse and quieter: the systems churches use to fix the first problem tend to hand a helper who is doing one shift at one supper a view of the whole congregation.

What bindro does: The rota is a record: one person, one session, a role and a start and end time, with today's shifts on the day-of page. Re-rostering somebody edits their shift rather than stacking a second one on top of it. And a shift grants no access to anything at all — what a person can see comes from the role they hold in your organisation and nothing else, checked on every request rather than by hiding a link. Someone on the door sees a name and whether that name is expected. Not what anyone gave, not anyone's allergies, not anyone else's booking.

The treasurer reconciles the harvest supper in March, and the funder asks in April

Cash in a tin, three transfers with no reference, a card reader belonging to somebody's spouse and a spreadsheet nobody else can open. By the time the accounts are done, nobody can say what the supper cost, what people gave on top or how many came who had never been before — and those are the three things a grant funder, a PCC or a church council will ask for, usually with a deadline.

What bindro does: Income comes off the same double-entry ledger the payouts settle against, so what the report says and what reached the bank agree by construction rather than by someone checking. Gross, fees and refunds are reported per event; gifts are stored apart from the price of a place, so "what the supper cost" and "what people gave" never merge into one number; free places consume real capacity and check in normally but write no income at all, so generosity never inflates what you report as taken. The board report gives you quarterly activity, attendance, free places and income as a CSV you can attach to a return, and the underlying rows export whenever you want them.

Pay-what-you-can, inside a band you publish

The place carries a floor, a ceiling and a suggested amount, and the household chooses inside it. The band is the church's, not the buyer's: the amount is checked against the published range server-side inside the transaction that confirms the booking, so a form that tries to send its own number is refused by name rather than believed.

• A floor of zero means a household can choose zero and still be signed up — no code to type, no conversation to have, no different queue at the door.
• The suggested amount is what most people pay, so it is worth setting to what the event actually costs you per head rather than to what you hope.
• Fixed prices and a published household rate work alongside it; the same event can have a full-price place and a pay-what-you-can place as two ticket types.
• Member and non-member prices exist as a model, but checking someone against a membership roster is not enabled for congregations — a member price here is a published price, not a verified entitlement.

Sign-ups by household, with the names filled in later

One person books however many places the household needs and the names can come afterwards. The order carries a household name, and each place becomes its own roster slot: whoever booked can fill the names in from a link, or send a place to the person taking it so a teenager or a friend enters their own details.

• A place nobody has named is not on the door list, and a check-in attempt against it is refused — which is what stops "the Nolans, four places" becoming four unaccounted-for people in a hall.
• The form asks for the household name, who is under 18, guardian details, dietary needs, access needs and whether the person can help — preconfigured, because this is what a church event asks.
• Allergy and access answers are classified as health information on the field itself, which keeps them out of every export and out of AI context absolutely, with no setting that changes it.
• The office can enter a booking directly for someone who paid by cash or cheque, through the same questions as a public sign-up, so an incomplete one is refused rather than half-created.

Consent the guardian actually gives, and waivers that record what was shown

Two separate things doing two separate jobs. A booking that includes a child raises a countersign request to the guardian's own email address, and the child stays off the door list until it is signed. A waiver is accepted by the person signing up, typing their name, with the wording and a digest of the wording stored against the order.

• A box ticked by the booker is the booker's commitment. The guardian's consent arrives from the guardian's own address, and bindro treats those as different events.
• The consent request is written in the same transaction as the payment, so there is one for exactly the bookings that exist.
• Refusing the door is the enforcement, not a warning list somebody is meant to check: an unconsented child is not on the offline manifest at all.
• Waiver acceptance stores the signer, the exact text as displayed and its digest, so a revision next year does not overwrite what this year's households agreed to.

Gifts on top, and a receipt that names the right number

There is a gift box on the sign-up form and no platform fee is charged on the gift. The gift is tender added to the sale rather than a discount or a second ticket: the form names who receives it, the payment page shows it on its own line, and the confirmed order keeps it apart from the price of the place.

• File your registered charity number in the console and a receipt goes to the giver after each paid order, quoting the number.
• The deductible figure is the gift alone and never the total — somebody who paid $45.00 for a retreat place received $45.00 of retreat, and a receipt implying otherwise invites them to claim relief they are not entitled to on a document that looks official.
• With no charity number on file the console says so, rather than quietly sending nothing.
• Gift income is reported separately from event income everywhere it appears, which is the distinction a treasurer needs and the one a generic checkout collapses.

A door that works in a hall with no signal

Offline check-in is a requirement for church events rather than an extra, so it is designed into the data model instead of retrofitted. The device holds the list, admits people with no connection at all, and reconciles when it reconnects. Congregations check in by name, so nobody has to have found an email on a phone with two percent battery.

• Offline check-ins replay on reconnect; replaying the same batch twice counts once.
• Two volunteers ticking off the same person produces a conflict you can see rather than a silent overwrite.
• Somebody who moves their car and comes back is checked in again at the door that first welcomed them, marked as a return with the time they first arrived; the same code presented at a different door while they are already inside reads as already used. The visit is counted once either way.
• An offline room count is as fresh as its last sync. If the office adds a walk-up booking on another device, the door will not see it until both are back on a connection — worth one sentence in the briefing.

Courses, series and the things the office does on a Tuesday

The ordinary week of a church office, without a support ticket for any of it.

• "Tuesdays at 7pm for eight weeks" is generated once and becomes eight sessions with eight place counts, each selling and checking in on its own. What congregations do not get is a term pass bought in one purchase — class packs are not turned on for this vertical.
• Free places for people who cannot pay: they consume a real place and check in normally, and write no income, so they never inflate what you report as taken.
• Promo codes for a group you want to invite, and refunds you issue yourself — proceeds reverse first, then tax, then our fee, so a refund never leaves the ledger unbalanced.
• Attendees can be emailed after the event, but only the ones who opted in and only once the event has actually happened; anyone who did not opt in is refused where the message would be queued, not filtered out by hand afterwards.
• Card disputes are handled as a defined path with the church debited in full and the evidence recorded, rather than as a surprise letter.

What the church council and the funder get

A board report with quarterly activity, attendance, free places given, income taken from the ledger and a breakdown by whatever your sign-up form asks — downloadable as a CSV to attach to a return. Reach, generosity and income stay three numbers rather than one, because a funder asking how many people came is not asking about revenue.

• Income figures come from the double-entry ledger the payouts settle against, not from a summary table written alongside it.
• Free places are counted separately from paid ones; gifts are counted separately from the price of a place.
• Orders and attendees export as a file you can open in a spreadsheet, on your own initiative, with no export fee and no notice period.
• Health information and anything belonging to a child never appear in an export or in any AI context, in any vertical, with no override.

Who pays the booking fee?

The attendee, unless you say otherwise. Every event carries its own setting — the attendee pays, you absorb it, or you split it — and the fee itself does not change with the choice, only which side of the sale it comes from. On a ten-place $25.00 event that is $16.20 either added to what attendees pay or taken out of what you keep.

Because the default is the attendee, a church can go from signing up to a sold-out event without paying bindro anything up front, at any point, ever. We are paid out of sales that happened or we are not paid.

The word "event" is load-bearing and worth reading twice. The scheduler groups by event, admits one only once its LAST session has ended, and pays it once. An event sold as a run of dates therefore pays after the final date, not after each one — a season's float is not something an operator should discover halfway through the season.

Bindro never pays before delivery, in any vertical. A pre-event advance is a configuration violation platform-wide rather than a policy someone can be talked out of, because paying out on events that have not happened is exactly how a cancellation becomes attendees with no refund. "Paid" also means the money moved: a payout only reaches its paid state with a real transfer reference attached, enforced by the database rather than by a status field someone can set.

• One payout per event, after its last session ends, one in flight at a time.
• T+2 for this vertical (low risk tier), no reserve.
• Refunds reverse in a fixed order — your proceeds first, then tax, then our fee — so a refund never leaves you charged for a sale that was undone.
• Sales tax, where it applies, is held as a liability rather than mixed into your balance, so the payout figure is proceeds rather than a number you still have to do subtraction on.

The three numbers underneath it are donation attach rate, volunteer fill rate and household return rate. Attach rate tells you whether the gift box is asking well or asking awkwardly; volunteer fill rate is the honest measure of whether the event was staffed or endured; and household return rate is the one that says whether the evening was any good, because a household that comes to the second supper decided something at the first.

The funnel this vertical is measured on runs from viewing the page to a household being added, consent being signed, the booking confirmed and the people attending — and the two places congregations lose people are the consent step and the gap between confirmed and attended. Both are visible: unsigned consents are the ones blocking a child at the door, and confirmed-against-checked-in is a no-show percentage per session.

The console computes participation per event and prints the arithmetic under it — people on paid places against the gatherings you have actually delivered — so the number is checkable rather than asserted. Until something has been delivered there is nothing to divide by, and it shows an em-dash rather than a zero.

What the console shows today, without an integration or a spreadsheet:

• Gross, platform fees and refunds per event, read from the ledger the payouts reconcile against.
• Places sold against attendees checked in, with a no-show percentage per session.
• Live remaining capacity while the event is running, per pool, on the day-of screen.
• This church's own funnel — view → household added → consent signed → confirmed → attended — stage by stage with the drop-off between them, and any step the platform cannot see said so rather than shown as a zero.
• Refunds, transfers, turnout, no-shows, add-on attach and repeat buyers, each printed with the two numbers it was divided from.
• Orders and attendees as CSV, so anything not on the screen is one export away.

Two more that are worth stating plainly. Sensitive answers are classified on the field rather than by convention, and health data is excluded from analytics exports and from AI context absolutely, with no override in any vertical. And a church's own people see only what their role allows — a door login sees a name and whether the code admits, not what anyone paid — which is checked in the handler rather than by hiding a button.

• Running background checks on volunteers. Bindro collects the safeguarding declaration before checkout and records who is rostered to which shift; it does not run DBS, police or reference checks, and it does not refuse a rota entry because a check is missing. That part stays with your safeguarding lead.
• Regular worship services. They are not ticketed, and this vertical deliberately excludes them — bindro has nothing useful to say about a Sunday morning.
• Recurring giving, standing orders and annual giving statements. Subscriptions are not resolved for congregations, and payouts settle per delivered event, so money taken outside an event would have nothing to settle against. It is off on purpose.
• Being a church management system. There is no membership database, no pastoral records, no worship-service planning and no Sunday attendance tracking. Bindro handles the event and hands you the data.
• Waitlists. When an event is fully booked it is fully booked — there is no queue that promotes people automatically when someone drops out.
• Membership-verified pricing. Member and non-member prices exist as a pricing model, but checking someone against a membership roster is not enabled for congregations, so a member price here is a published price rather than a verified entitlement.
• Multi-day retreat agendas where each person picks their own sessions, class packs, document upload, add-on merchandise, invoicing a partner organisation, gift cards, season passes and sales tax. All configured as optional for congregations and none currently turned on — a direct call to any of them is refused, not quietly ignored.

If one of those is the thing you need, say so — the answer is a capability declared, built and gated properly, or a straight no. It is never a feature flag that collects the request and does nothing.

This vertical's tagline says "with safeguarding built in", and that phrase is doing less work than it sounds like it is doing, so here is the line drawn plainly. What is built in is the paperwork the platform can genuinely hold: a blocking declaration before checkout, a guardian countersign that the door enforces, a rota with named people on named shifts, and an audit record written in the same transaction as the thing it describes.

What is not built in is any form of vetting. There is no background-check integration, no clearance status on a volunteer record, and no gate that stops you rostering somebody who has not been checked. A church that read this page as "the software handles safeguarding" would be worse off than one that read nothing, because they would stop doing the part that matters — and that is the single most damaging misreading available on this vertical, which is why it is on the landing page rather than the FAQ.

The related boundary is worth stating in the same breath: being on a rota grants no access to anything. Permissions come from the role a person holds in your organisation, and a volunteer helping at one supper does not thereby acquire a view of the congregation. If your policy is that only cleared adults are rostered with young people, bindro will record who you rostered; enforcing the policy is still a person's job.

• Built: blocking safeguarding declaration, guardian countersign enforced at the door, rota of who is on which shift, role-based access, audit records.
• Not built: DBS, police or reference checks, clearance status, or any refusal based on one.
• Consequence: your safeguarding lead still owns clearance, and no report here should be shown to anyone as evidence of vetting.

The arithmetic is small enough to do here. A 60-place retreat with a $45.00 suggested amount takes $2,700.00 if everyone pays it, and carries $127.20 in platform fees — 2.5% + $0.99 per paid place. Nothing is charged on the places priced at zero, so a household who chose your floor costs the church only what the church was already spending on them.

The suggested amount is the whole mechanism. People overwhelmingly want to pay their share and mostly do not know what their share is, so a form that offers them a figure is telling them, and a form that offers a blank box is asking them to guess in public. Set it to your real cost per head rather than to what you hope, and let the gift box carry the ambition instead — a gift is a separate line, carries no platform fee, and is receipted separately.

For a pay-what-you-can event most churches absorb the booking fee, so that the number a household chooses is the number they are asked for. That is a per-event setting, and the fee does not change with the choice, only which side of the sale it comes from. The full arithmetic, including what to do when the band is not covering costs, is worked through in the pay-what-you-can guide.

Publish first and link it everywhere you already publish — the pew sheet, the weekly email, the church website. The hosted page carries the band, the dates and the questions; the embedded version puts the same checkout inside your own site for the churches that would rather people never left it.

While sign-ups are open, the two things worth watching are places remaining and consents outstanding. The second one is the one that ruins a Saturday morning: a child whose guardian has not signed is not on the door list, and the fix is an email three weeks earlier rather than a phone call in a car park.

On the day, one person on the door with the list on a phone, working whether or not the hall has signal, ticking households off by name. Volunteers see today's shifts on the same screen. Nobody at the door can see what anyone gave, which is the point of the name list.

Afterwards: attendance against sign-ups, gifts separately from place income, free places counted as reach rather than revenue, an export for the treasurer and a thank-you email to the households who opted in. Then one payout for the retreat, two days after its final session, with no reserve held back in this vertical — and never before, because money for an event that has not happened is money that has to be there to give back.

• Publish the retreat with a band, a suggested amount and a place count.
• Link it from the pew sheet and the weekly email, or embed the checkout in the church site.
• Watch two numbers while it is open: places remaining, consents outstanding.
• Run the door from the offline name list; volunteers see their shifts on the same page.
• Export for the treasurer, report reach and income separately, email the households who opted in.

A church management system knows your congregation — who is a member, who is in which group, who was visited last month. That is a different job from holding sixty places in a hall, refusing a child whose guardian has not countersigned, and checking a hundred and twenty people in from a phone with no signal.

A giving platform knows recurring gifts, standing orders and annual statements. Bindro deliberately does none of that: subscriptions are not resolved for congregations, and payouts settle per delivered event, so money taken outside an event would have nothing to settle against. The gift box here is an addition to an event sign-up, receipted against your charity number, and it is not a giving programme.

The place the overlap is real is one-off event registration, and that is what the three comparison pages below are about. Each one names where the other tool is genuinely stronger, because a comparison with no such section is an advert and you would be right not to believe the rest of it.

The form already asks the household name, who is under 18, the guardian's name and their own email address, dietary requirements, access needs, the waiver signature and whether the person can help at the event. It also already refuses to store an answer to a question you did not declare, because an undeclared field is an unaudited channel with no sensitivity class, no retention rule and no exclusion from exports.

The two compliance requirements — parental consent for minors, and the safeguarding declaration — arrive attached to the vertical rather than as something you remember to add. Both are blocking, which means they are asked before money moves rather than chased afterwards.

And the pages say "event", "place", "attendee" and "church" because that is what a church says. A vertical config whose primary call to action is generic ticketing wording fails validation rather than shipping, which is the shortest available explanation of what this platform is for.