Self-Exclusion Enrollment Form

This form is for venues or programs that maintain a voluntary self-exclusion list and need a consistent way to enroll a patron. It is typically used by compliance staff, security, guest services, or a designated program administrator. The form helps document identity, the chosen exclusion period, and the patron’s acknowledgment of the program terms. It is not meant for general customer intake or incident reporting.

The template collects program acknowledgment, consent to collect PII, identity details, contact information, an exclusion period, a photo, and a signature. It also includes an attestation so the patron confirms the information is accurate and the enrollment is voluntary. The fields are structured to support validation and an audit trail without collecting unrelated data. If a field is not needed for your program, it should be removed rather than made optional by default.

It is usually completed once per enrollment event, then retained as the record of that patron’s exclusion request. Some programs may reopen the form if the patron updates contact details, changes the exclusion period, or re-enrolls after expiration. The form is not a recurring check-in unless your policy requires periodic review. If your workflow includes renewals, add a separate renewal step instead of overloading the original submission.

Because this form collects PII and a photo, it should follow data minimization and clear consent practices. The template supports a disclosure section, which helps explain what is collected, why it is collected, and what happens after submission. If your program is tied to regulated gaming, hospitality, or safety policies, review local rules for retention, access control, and recordkeeping. Keep the form limited to what the program actually uses.

Yes. The exclusion period field can be configured as a single-select list, a date range, or a custom duration with conditional logic for the 'other' details field. That makes it easy to support fixed terms, indefinite exclusions, or jurisdiction-specific options. If you offer multiple program types, use progressive disclosure so only the relevant period choices appear.

The most common mistake is collecting too much information up front, especially fields that are not needed to verify identity or process the exclusion. Another frequent issue is using free-text fields where structured inputs are better, such as date picker, phone validation, or last-four-only ID capture. Forms also fail when they do not clearly state whether the patron can submit anonymously or whether a photo is required. This template avoids those problems by separating disclosure, identity, photo, and attestation.

The photo field should be treated as a required attachment only if your program truly needs it for enforcement or verification. The signature field should capture a clear attestation that the patron understands the exclusion terms and is submitting voluntarily. If your workflow supports e-signature, keep the signature date and audit trail tied to the submission event. Avoid asking for a handwritten signature image if a compliant electronic signature is sufficient.

Yes. It can be connected to case management, CRM, document storage, or access-control workflows depending on how your program operates. Common integrations include file storage for the photo, notifications to compliance staff, and a record export for audit review. If you integrate it, make sure only the minimum necessary data is passed to each system.

An ad-hoc process often misses required disclosures, uses inconsistent fields, and creates gaps in the record. This template standardizes the enrollment flow so staff collect the same information every time and can verify that the patron reviewed the terms. It also makes it easier to enforce validation, required vs optional fields, and a clear submission outcome. That reduces rework and helps preserve an audit trail.