Safety & Compliance Training 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 "seat" and "course" because that is what a training centre says; a config whose primary call to action is generic ticketing wording fails validation rather than shipping.

The people who pay for the course are never the people in the room

Safety training is bought by a company and consumed by an individual, and nearly every booking tool in existence is built for the individual. A safety manager takes six places on an OSHA 10 for people whose names nobody has decided yet, finance will not release a card number for a training course, and the trainees themselves have no say in any of it. Push that through a consumer checkout and a training centre ends up with six separate bookings, a card payment that was never going to happen, and a chain of forwarded emails standing in for a purchase order.

What bindro does: Billing the employer is a control on the booking form here, not a process somebody has to run afterwards. Because this vertical declares invoicing, the buyer chooses to have their organisation billed, names it along with the accounts-payable address, types their own purchase-order reference and finishes without a card being asked for at any point. The bill is raised inside the transaction that commits the seats, numbered gaplessly for your training centre, and emailed to the address they gave with their PO quoted back — which is the field that lets an accounts-payable system match a bill to a commitment and actually release it.

Finance pays on their own schedule and the course runs on Tuesday

Terms of net 30 against a course that runs next week is the ordinary arithmetic of this trade rather than an awkward exception. The seats have to be held, the trainer has to be committed and the rig has to be booked long before the money appears, and a system that treats an unpaid booking as a provisional one leaves a training centre choosing between turning away a good employer and running a course it cannot count on. The other half of the same problem is the invoice nobody ever pays, which in most tools is discovered by reading a spreadsheet in the wrong week.

What bindro does: A booking taken on a purchase order is a real reservation, not a pencilled one: the seats are committed, the trainees are on the door manifest, and the door admits them normally whether or not finance has done anything yet. What bindro deliberately does not do is chase. One invoice email goes to the accounts-payable address and nothing follows it — no reminder, no statement, and no way to record a part payment — and a bill still unsettled on day thirty is voided by the sweep, which cancels the booking, returns the seats to the pool and drops those trainees off the list. That is a sharp consequence, so it is on this page rather than in a release note: watch the Invoices screen in the last week.

Nobody knows who is coming until the morning of the course

An employer buys capacity and decides on people later, and often much later than a training centre would like. The six names for next Thursday are settled by a supervisor on the shop floor the night before, two of them change because of a shift swap, and the list arrives as a photograph of a handwritten note. Meanwhile the trainer needs a register, the awarding body needs a full name per person, and the certificates cannot be produced for people the system has never heard of.

What bindro does: Seats and people are separate things here, which is what the trade actually needs. A booking of two or more seats creates a roster with exactly one place per seat paid for, and the confirmation gives whoever booked a link to it. Places can be named late and re-named at any time, including after the bill has been settled, and the new person's name and answers replace the old ones on the register. Nobody can add a seventh person from that link, and a place still unnamed on the day is refused at the door — which is deliberate, because a blank on the register becomes a certificate that names nobody.

Somebody arrives without the prerequisite and cannot be trained

A confined-space entrant without the medical, a rigger without the prior ticket, a sixteenth birthday that has not happened yet: every one of these is a person standing in your classroom who cannot be put through the course. The seat is gone, the ratio is wrong, the employer is annoyed and the awarding body would not accept the paperwork anyway. Collecting the evidence by email before the day is the standard workaround, and it fails in the standard way — the attachment is in somebody's inbox and the booking has already been confirmed.

What bindro does: The refusals happen where they cost nothing, which is on the money path. Evidence of the prerequisite qualification is a required file on the booking, so checkout cannot complete without it and the file is claimed onto the order as it confirms — a reference borrowed from somebody else's checkout is rejected rather than quietly accepted. The floor of sixteen is a hard rule on the date of birth rather than a tick-box attestation: a younger booking is refused inside the confirm transaction, with the rule named and the error anchored to the field, and no order and no payment exist afterwards. Questions can also be asked conditionally on an earlier answer, enforced on the server rather than only in the browser.

The register is a clipboard and the certificates are typed from it a week later

The place a training centre delivers is frequently the worst-connected building it will enter all year: a plant floor, a basement plantroom, a site cabin, a warehouse with a steel roof. So the register is paper, and paper is where the money leaks. A name is illegible, somebody who left at lunch is marked present for the whole day, and a week later an administrator is typing certificates from that sheet into a template — which is the point at which a certificate gets issued to a person who was not there, and the training centre has attested to something it cannot evidence.

What bindro does: The door here is a name list that works with nothing at all behind it. A device syncs a signed manifest of the names before the course starts, validates entirely on the device with no network, and uploads its log when it is back on a connection; a re-upload counts as duplicates rather than marking anybody twice, and the same person marked in on two devices surfaces in a conflict queue for a human to settle instead of resolving itself quietly. Certificates then read that register rather than the payment: one per trainee with a check-in record, at the session's scheduled contact hours, each with its own serial, and somebody who paid and never arrived gets nothing.

The same eight courses, retyped into a calendar every quarter

An open-course schedule is repetitive by design: the same forklift refresher every other Tuesday, first aid on the first Monday of the month, confined space whenever the rig is free. Retyping that into a booking system four times a year is an afternoon each time and a source of quiet errors — a date that never went on sale, a classroom course published with the rig's capacity of eight, a session sitting in the wrong month. None of it surfaces until an employer cannot book something you believe is bookable.

What bindro does: A schedule is generated rather than typed. A cadence — Tuesdays at nine for eight weeks — creates every session and its own seat pool in one transaction, so each date sells and fills on its own, and capacity is per session, which is exactly what a centre needs when the confined-space rig takes eight people and the classroom takes twenty. One thing to hold in mind while you build it: sessions generated together belong to one course and are therefore paid as one course, so a centre that wants to be paid monthly should create each month as its own course rather than running a single series across the year.

An invoice raised in the same breath as the booking

The billing path is complete and short, which is the point: an employer books, the bill exists, and no human at your end has typed anything. The invoice is created inside the confirm transaction rather than by a job that runs later, so there is no window in which seats are committed and no bill exists, and the numbering is gapless per training centre because a sequence with holes in it is the first thing an auditor asks about.

• The purchase-order reference is a first-class field the employer types at checkout, stored against the invoice and echoed in the invoice email.
• Terms are a fixed net 30 across this vertical; they are not per-employer and not negotiable in the product.
• Settlement is a person in your console marking the bill paid with the remittance reference the money arrived on — the reference is required, and the same bill cannot be settled twice.
• That settlement is what writes the payment row and credits your balance; an unpaid invoice has moved no money anywhere, so a void reverses nothing.
• What is absent, stated plainly: reminders, statements, part payments, per-employer credit limits and any kind of receivables ageing.

One purchase order, six seats, and a register that can change all week

Block booking is the median sale in this trade rather than a special case, so it is built as one order with one bill and one roster rather than as six bookings that have to be reconciled afterwards. The employer commits to capacity on Monday and decides on people whenever the shift pattern allows, and the training centre sees the register fill in rather than chasing it.

• Six seats raise one invoice for the whole amount and create exactly six places.
• Any place can be typed and re-typed from the roster link at any time, including after the bill has been settled.
• It is a rename rather than a handover: nobody is notified automatically, so tell the first person if you have already sent joining instructions.
• The seventh person is refused — a roster cannot grow past the seats that were paid for.
• Seats inside one block cannot be split across two different course dates; that is two bookings.

Eligibility refused at checkout instead of discovered at the door

Everything an awarding body requires before a place can exist is asked for during the booking and enforced as the order confirms, which is the only moment where refusing is free. A refusal on the money path costs an employer thirty seconds; the same refusal on the morning of the course costs a seat, a ratio and a relationship.

• The prerequisite certificate is a required upload — a scan or a photograph up to five megabytes, held against the booking and claimed onto the order as it confirms.
• One document per booking rather than one per trainee, which is worth knowing before you publish a link for a block of six.
• The minimum age of sixteen is checked against the date of birth inside the confirm transaction, and an unparseable date is refused rather than waved through.
• A higher floor set by an awarding body for its own course is not modelled, so that check stays yours at enrolment.
• Conditional questions are declared on the field itself, so the hosted form and the JSON API enforce exactly the same rule.

Certificates minted from the register, and a straight answer about what they are

This is the feature with the sharpest edge on the page, and both halves belong on it. What bindro does is real: after a session has ended you open Credits and issue for that session, and it mints one certificate per trainee with a check-in record, at the session's scheduled contact hours, each carrying its own serial. Re-issuing the same session duplicates nothing and a session that has not finished is refused. What it is not is an awarding body, and the word "automatically" does not survive contact with this vertical.

• Nothing is transmitted to OSHA, to a DOL outreach programme, to the American Heart Association or to any other body — no agency is integrated anywhere in the platform.
• The deliverable is your own certificate of attendance: your training centre's name, the trainee, the course, the date, the contact hours and a verifiable serial.
• Cards, eCards and scheme submissions stay exactly where they are today, with you.
• Issuance is your action rather than a scheduled one, so the timing you promise employers is a promise about your admin, not about ours.
• No expiry or renewal date is stored and nothing emails anyone about a lapsing certificate; the three-year refresher chase is built from the attendee export.

A door that works in a building with no signal, and staff who see only the register

Safety training checks people in against a name list, and the list is designed to work in the places this trade actually delivers in. The manifest is signed and validated on the device, so admission does not wait on a network, and the reconciliation afterwards is designed around the two things that genuinely go wrong: a device that uploads twice, and two devices that disagree.

• The manifest syncs before the course, the device validates against it with no connection, and the shift log uploads when it finds a network.
• A re-upload counts as duplicates rather than double-marking anyone.
• The same trainee marked in on two devices lands in a conflict queue for a human to settle rather than resolving itself.
• A trainer can find and admit a name by hand from any browser, which is what a room of twelve people usually needs.
• What somebody can see is decided by their role: a trainer on the door sees the register and not what anybody paid, checked in the handler rather than by hiding a button.

A schedule generated once, and tax that stays a liability

The two pieces of administration that quietly consume a training centre's week are publishing the schedule and working out what of the money is actually yours. Both are handled by the engine rather than by a spreadsheet, and both are visible in the same console.

• A cadence generates every session and its own seat pool in one transaction, with capacity set per session rather than per course.
• More than one ticket type can stand against the same course — an open-course seat and a block rate published for employers.
• The price is derived on the server at the moment of payment, so a page somebody left open last week cannot buy last week's price.
• Sales tax is added on top of the seat in the US price-exclusive way, itemised at payment, stored inside the charged total and reversed proportionally on a refund.
• Collected tax is never treated as your revenue and cannot be paid out to you, so the balance you see is proceeds rather than a figure you still have to subtract from.
• Inclusive VAT is a separate capability that this vertical does not claim, which makes bindro a US-only tool for safety training today.

Who pays the booking fee?

The trainee, unless you say otherwise. Every course carries its own setting — the trainee 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-seat $25.00 course that is $16.20 either added to what trainees pay or taken out of what you keep.

Because the default is the trainee, a training centre can go from signing up to a sold-out course 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 course, admits one only once its LAST session has ended, and pays it once. A course 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 courses that have not happened is exactly how a cancellation becomes trainees 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 course, 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 reason the arithmetic is worth doing per course rather than per month is that a safety training business fails quietly. An open course that runs at a third full does not look like a problem on a bank statement — the money came in, the certificates went out — and it is only when the same course runs a third full four times in a row that a centre discovers it has been paying a trainer to teach empty chairs. What you need to see that is sold against capacity for each session, which the day-of screen shows live while a course is filling and the export carries afterwards.

The three numbers this vertical is configured to watch alongside it each have an honest answer about where they come from. Employer repeat rate is yours to compute from the attendee and order exports, which carry the organisation an employer named when they were billed. PO cycle time is measured for you (B21): the median gap between raising a bill against a purchase order and somebody marking it settled with a remittance reference, counted across the bills that were actually paid — an unpaid one is left out rather than counted as nought days, which would make your slowest employer look like your fastest. Certificate issuance latency is the gap between a session ending and you pressing issue — which is a measure of your own admin rather than of the platform, since nothing issues on a schedule.

What the console will not do is tell you why a course under-filled, and there is no waiting list here to tell you how much demand a full course turned away. A full course reads "Course full" and takes no names, so the only evidence that you should have run two is the enquiries that reached you directly. Publishing the next date early is the workaround the trade already uses, and it is the one this platform supports.

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

• Gross, platform fees and refunds per course, read from the ledger the payouts reconcile against.
• Seats sold against trainees checked in, with a no-show percentage per session.
• Live remaining capacity while the course is running, per pool, on the day-of screen.
• This training centre's own funnel — view → date selected → details → PO raised → confirmed → attended → certified — 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 trainees 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 training centre'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.

• Awarding-body cards and submissions — no agency, scheme or regulator is integrated anywhere in the platform. Bindro issues its own certificate of attendance with contact hours and a serial; the OSHA or DOL card, the eCard and the scheme submission stay exactly where they are today, with the training centre.
• Filing a certificate with the awarding body — a certificate carries its expiry, and the employer screen prompts you before it lapses, but nothing is transmitted anywhere. You issue the document; reporting it stays with your training centre.
• Swapping the named trainee on a single-seat booking — ticket transfer is not declared for this vertical and the control does not render. A booking of two or more seats can be renamed from its roster link, which is the real answer for an employer.
• A waiting list for a full course — the waitlist capability is not declared here, so a full course shows "Course full" and takes no names. Publishing the next date is the workaround.
• Payment plans — instalments are not switched on for safety training. An employer either pays the whole seat by card or takes the whole booking on a purchase order.
• A group rate on a seat — the group price and its threshold live on the ticket type and nothing in the product writes them, so a block-booking discount has to be a promo code, a member rate, or a separate ticket type priced for employers. A MEMBER price can be set (B21): a trainee quoting a current membership number is quoted it on the money path.
• Chasing an unpaid invoice — one invoice email goes to the accounts-payable address and nothing follows it. There are no reminders, no statements and no partial payments, and an invoice still unpaid at day thirty is voided, which cancels the booking.
• Selling a whole multi-day course as one hosted-checkout order — the hosted flow still sells one session per order and the multi-day agenda ships on the public JSON API.
• Printed badges, course material and online testing — there is no badge printing for this vertical and no learning platform anywhere in bindro. Nothing hosts a slide deck, marks a test or delivers an e-learning module.

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.

It is worth being precise about why that distinction is on the landing page rather than buried in an FAQ. "Can I have a rate for six people" is the first question a training centre is asked by any employer worth having, and a platform that lists a group rate among its pricing models has effectively answered yes. Bindro would have to answer no at the point somebody tried to configure it, which is the worst possible place to find out — after the migration, in front of the customer.

The controls that do exist are not a consolation prize. A promo code is issued to one employer, has its own redemption rules, and comes off the server-derived price at the moment of payment, which means it cannot be applied by editing a URL. A separate ticket type is better where the discount is permanent rather than negotiated: publish a block rate that sits alongside the open-course seat, price it for the volume you want to encourage, and every employer sees the same terms — which is frequently what a centre wanted in the first place.

Comp seats are the third control and the one people forget. An apprentice a client is sending as a goodwill gesture, a regulator observing, an internal staff member sitting in to keep their own ticket current — all of them can hold a real place on the register at no charge, which means they appear on the manifest, are admitted at the door and receive a certificate exactly as a paying trainee does.

The practical answer most training centres reach is simpler than either path. A confined-space course delivered over three consecutive days is usually published as one session of the right length — the register is taken once, the contact hours on the certificate are the whole course, and the employer buys one thing. That is the shape the hosted checkout handles cleanly today, and it is the right shape whenever attendance on every day is compulsory anyway.

Where the per-day model earns its complexity is a course somebody can legitimately attend part of, or a modular programme where the days are sold separately. There, one credential per person per day is exactly right, because a credential that admits anywhere would let a trainee walk into day three without having sat day one. Bear in mind what that implies for certificates: issuance reads the register per session, so a missed day produces no certificate for that day even though the rest do, and what you do about the missed day is your policy rather than a platform behaviour.

Whichever way you build it, one rule decides your cash flow and it is worth reading twice. Sessions belonging to one course are paid as one course, once its final session has ended. A programme published as a single course running from January to June is one payout in June, not six monthly ones — so a centre that needs the money monthly builds each month as its own course, which takes a minute at setup and is impossible to fix halfway through a series.

The reason a human types a reference rather than a button simply saying "paid" is that a payment recorded against nothing traceable is how a ledger quietly acquires money that never arrived. The reference is required, the same bill cannot be settled twice, and the grant needed to do it is the same one that allows refunds — so settling an invoice is deliberately not something every account in your organisation can do.

Two things are taken out of the figure before it is yours and both are visible. Sales tax collected on a seat is held as a liability rather than mixed into your balance, because it was never your revenue. Refunds reverse in a fixed order — your proceeds first, then tax, then our fee — so a refunded seat never leaves you carrying a charge for a sale that was undone. The rest is proceeds, and it is the same ledger the payout is reconciled against, which is why the console's figure and the bank's figure are the same figure.

One case is worth planning for because it has no automatic handling. A booking settled by bank transfer against an invoice, or taken over the phone and recorded as an external payment, has no card charge sitting behind it — so bindro cannot refund it, and you return that money the way you took it. The booking is cancelled in the console as normal and the seat goes back into the pool; only the movement of money is yours to make.

The first is the one that decides it. If your current system submits to an awarding body on your behalf and that submission is load-bearing for your accreditation, then nothing here replaces it, because no agency is integrated anywhere in this platform. Bindro issues its own certificate of attendance from the register and sends it nowhere. Plenty of centres do their submissions on a portal already and lose nothing by moving; a centre whose whole compliance loop runs through the tool would be migrating into a gap.

The second and third are narrower but sharp. Bindro sells scheduled courses to a room, and it does not host material, mark a test or deliver an e-learning module — a blended programme with an online component keeps whatever delivers that component. And the billing path stops at one invoice email: if your business genuinely depends on reminders, statements, part payments and credit control, that work stays with your finance function, and the day-thirty void is a deadline you have to watch rather than one you can let run.

The fourth is small and comes up constantly, so it is worth rehearsing before you switch. A trainee who cannot make the date is deferred rather than refunded: the order screen issues a course credit, good for twelve months, that the employer redeems against a later run — and until it is spent the money sits on a liability rather than counting as yours. A block of two or more seats has a second answer, because the roster rename lets an employer simply send somebody else. Decide which you want to offer and put it in your own terms rather than leaving them to guess.