# Event registration bot-abuse decision sheet

Copy this sheet for each registration, RSVP or waitlist flow. Fill in measured observations before changing defenses. Sample values below are prompts, not universal thresholds.

| Field | Record |
| --- | --- |
| Event and form URL | |
| Form owner and technical operator | |
| Ticket or seat inventory affected | |
| Observation window and time zone | |
| Normal completed registrations in a comparable period | |
| Suspected submissions and why they are suspicious | |
| Confirmed effect: occupied seats, waitlist, email, support, payment or other | |
| Evidence location (avoid copying attendee data here) | |
| Decision owner and next review time | |

## Triage each signal

| Observed signal | Possible innocent explanation | Check in the source of truth | Proportionate response | Accessibility or false-positive risk | Owner | Review result |
| --- | --- | --- | --- | --- | --- | --- |
| Sudden submission burst | Marketing announcement or group sign-up | Campaign schedule; completed versus abandoned registrations | Investigate before throttling | Legitimate launch traffic could be delayed | | |
| Many unconfirmed RSVPs | Mail delivery problem or mistyped addresses | Confirmation status and bounce reports | Verify message path; limit repeated sends if necessary | Real guests may need help correcting email | | |
| Repeated identical form values | Shared group contact or automated replay | Deduplication and order IDs | Server-side validation and idempotent handling | A group buyer may use one address | | |
| Challenge failure spike | Widget outage, blocked script or inaccessible puzzle | Server verification errors and support contacts | Repair or pause faulty challenge; provide assisted route | Genuine guests can be excluded | | |

## Control and review record

| Control | Endpoint or journey | Server-side enforcement? | Rollback owner | How a guest gets help | Metric before | Metric after | False positives checked? |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Input and business-rule validation | | | | | | | |
| Rate or resource limits | | | | | | | |
| Email or account confirmation, where appropriate | | | | | | | |
| Bot challenge, if justified | | | | | | | |
| Seat-hold expiry and inventory reconciliation | | | | | | | |

Before closing, check one real attendee journey in an approved safe manner: form input, confirmation, actual ticket or seat status, and support route. Do not count a challenge pass as proof that a person will attend. Do not block whole regions or shared networks merely because one signal looks unusual.