A system built so no inquiry, no signed agreement, and no follow up ever slips through the cracks

Every prospective student gets exactly one row on the board. The columns are the stages of their journey: Inquiry → Contacted → Registered → Agreement Signed → Access Granted → Attended/CE Issued. The system moves a row forward automatically whenever the person actually does something: inquires, pays, signs, finishes the course. Staff step in only for the parts that genuinely need a human: following up, correcting a mistake, approving a refund. The board tracks the person, not individual orders; a full order history stays in WooCommerce.

Built on WordPress and WooCommerce here, but that's not what makes it valuable. That part is built to be swapped out. The pieces that actually do the work, matching people by email, never double booking a card, moving someone forward only when they really did something, don't care which website or payment platform is feeding them. A different client on a different storefront or a different form tool would mean rebuilding the connections at the very front of the system, not rebuilding the system itself.

Inquiry isn't a required first step. It's simply the earliest event the system knows how to react to. Plenty of real people never fill out that form at all, they call the number on the website, message the team on social media, meet someone from the team at an event, or just decide to buy outright. Any of those paths still lands the person on the board, just starting from whichever stage matches what they actually did (someone who goes straight to purchase lands directly at Registered, see stage 3 below).

This walkthrough follows one person, Maria, a dentist considering the certification, through every stage below. Watching one real person move through the whole system makes the pattern clear in a way a list of rules on its own doesn't.

Built to hold up: security by default

Security isn't a feature bolted on at the end here, it's how everything was built from the first line. That difference lives in the details your team never has to think about, because they were handled up front:

• Passwords and access keys are stored somewhere only the system can reach, never in a place a website visitor or hacker could stumble onto.
• Sensitive files, like customer documents, can't be found by guessing a web address.
• The forms and systems that feed this board can't be faked by an outside party pretending to be a real customer.
• New code gets checked for security holes before it ever goes live, not after something goes wrong.

This is built to hold up, and to keep holding up as it's handed to your team and extended over time.

Want the technical proof behind that claim? The real bugs this system caught along the way, and exactly how each one was actually verified, are documented in the companion technical writeup.

Payment

Checkout runs on Stripe, in test mode, no actual charges. Registered reflects an actual test payment, not a placeholder, riding the same automation from order to Registered already described above. Stripe never needed its own automated step: it's a WooCommerce payment plugin, so a paid order looks the same to the board no matter which gateway processed the card.

The system's own bookkeeping

Behind the scenes, a small internal table keeps track of which automated actions have already run, so a webhook or check that accidentally fires twice can't send a duplicate email, issue a duplicate certificate, or advance a card twice. Staff never open it and never need to; it holds a single field: a one line marker for each action already taken. There are no names, no courses, no order totals, no message content and no notes.

One thing to be aware of, though: to keep those markers unique per person, many of them have the customer's email address built into the marker text (for example, agreement-signed-claim-maria@example.com). So while this table holds no customer record, it does contain email addresses. That matters practically in two ways: it's in scope for a data deletion request, and access to it should be treated like access to any other table holding personal data, not as a purely technical scratch pad.

If something breaks

If part of this stops working, the system says so. That notice goes to whoever supports the system, not to your team's channels, since "a connection failed" isn't something staff can do anything with.

The part to know: silence isn't proof that everything is fine. If you're waiting on something that never arrived, a card that never moved, an agreement that never went out, tell whoever supports the system instead of assuming it's on its way. They can see every run the system has made and exactly what went wrong.

1. A returning inquirer buys. The same row updates, it isn't duplicated (Inquiry to Registered on one card).
2. A cold order (never inquired first). A fresh row appears directly at Registered.
3. Source vs. Stage, the biggest source of confusion. Source is how they first arrived and never changes ("Website inquiry" stays even after they buy). Stage is where they are right now, and only ever moves forward.
4. A refund, hold, or withdrawal is always a manual staff change. Automation only ever moves someone forward; exceptions are human decisions.
5. Someone who's already moved further orders again (say, they're already at Agreement Signed). The system won't knock them backward; a notification fires so a human can look into it.
6. Staff advance someone by mistake. The system still protects that stage from going backward; a human corrects it, and the notification that already fired prompts them to look. Automation never undoes a human's forward move.
7. A customer accidentally reorders (a duplicate order). No duplicate row gets created and the stage stays protected; a notification lets a human catch and refund the double. The board tracks the person, not the order.
8. A returning inquirer inquires again (a follow up question, or an accidental resubmit). Same protection as situation 5, just from the inquiry side. A brand new person gets a fresh card at Inquiry. Someone who already inquired but hasn't moved further gets their same card refreshed with the new message, no duplicate. Someone who's already moved past Inquiry still gets their message logged, but their stage is never pushed backward. Every resubmission also sends the team a fresh Slack ping and email with whatever she wrote this time, not just on the very first one. Maria emails a follow up question after she's already registered: her card picks up the new note but stays at Registered, not knocked back to Inquiry, and staff still get notified of her new message.
9. A customer buys a different tier than they originally asked about. The card's tier always updates to reflect what they actually bought, automatically, every time, never a stale snapshot of their first question. But if she'd already paid for a cheaper tier and later decided to upgrade, crediting that earlier payment toward the new total is a manual staff step in your payment processor; the system has no billing logic and won't calculate or apply any credit on its own. Maria asks about Online Training, then decides to upgrade before ever paying: her card just shows the tier she actually bought, automatically. Had she already paid and then decided to upgrade, a staff member would need to manually credit that payment toward the pricier tier, same as any refund or adjustment.
10. Staff accidentally uncheck "Attended" on a record that's already been certified. Nothing happens, on purpose. Once a certificate has been issued, that record permanently falls outside what the system looks for next, so toggling that box afterward can't trigger a resend, an unsend, or any error. The three other independent records of the certificate, described in the previous section, still exist regardless; a single accidental click can't make a certificate unhappen.
11. Staff enter a completion date that doesn't make chronological sense (before the agreement was even signed, or a date in the future). The certificate is not issued. The system catches this automatically, alerts staff once by Slack and email so it doesn't get missed, and stops there. Fixing the date is all it takes; the next check picks it up normally. This exists because a CE accredited certificate with an impossible date is a real audit risk, not a cosmetic typo.

The "Uncategorized" column is a triage signal

Almost always this column stays empty, and a card sitting there means a human or an import added a record without a stage. Drag it to where it belongs.

One normal exception: when a new order arrives from someone who has never been on the board before, the system creates their row first and stamps their stage a moment later. For those few seconds the brand new card legitimately appears here. If you refresh and it's gone, nothing was wrong. Treat a card as needing attention only if it's still sitting in Uncategorized after a minute or so.

"+ Add contact" is for manual entry

For people who didn't come through the website (a phone lead, a referral, a walk in, an offline registration), click "+ Add contact" in the right column and fill in the details. They drop onto the board at that stage. The board captures everyone, not just the automated entries.