Training Operations Check-In Application

No stakeholder asked me to build a check-in application. I found the problem while repeatedly helping reconcile paper attendance records for a statewide training organization.

Expected attendees were printed; walk-ins wrote details by hand. Staff researched attendee and employer identifiers, calculated credit hours, and rebuilt the class record for external reporting. By firsthand estimate, one class could take more than an hour to reconcile.

I designed and built a role-aware application around the full operational path—not just digital sign-in. It supports public check-in, trainer attendance, coordinator review and reporting, administrative control, source matching, credit calculation, and continuing support.

Backlogs could arrive in batches of approximately five to ten classes. The consequential problem was post-class reconciliation: fragmented identities, incomplete data, attendance rules, credit calculations, and a reliable coordinator-ready report.

• Print the known roster.
• Capture unexpected attendees by hand.
• Return physical sheets from around the state.
• Interpret handwriting and fill gaps.
• Research attendee and employer identifiers.
• Calculate attendance and approved credit.
• Reconstruct the regulatory report.

The public experience had to be simple while trainers, coordinators, and administrators needed different controls. Credit depended on attendance and class conditions; exceptions had to be corrected without weakening the audit trail.

Replacing paper immediately would make the first live class the only record if a rule or usability problem surfaced. Privacy also rules out production screenshots as public proof.

I recognized the problem, defined the product, designed attendee and staff experiences, built the production application, connected maintained source information, implemented rules, created reports, planned the pilot, managed releases, validated behavior, corrected defects, and continued support.

This was end-to-end product ownership outside my primary employer.

I designed for the whole reporting lifecycle: check-in ends with a structured coordinator output, not a digital signature list.

Maintained source data reduces what attendees must know. Separate experiences reflect attendee, trainer, coordinator, and administrator responsibilities.

A live July 2026 class ran beside paper to reduce risk. A later credit-hour edge case was corrected through the release process, followed by regression, UAT, performance, and kiosk smoke checks. The honest story is disciplined production ownership, not a flawless first release.

The Google Apps Script and Google Sheets application includes a public kiosk, staff authentication, role-aware navigation, class management, check-in/out, unexpected attendees, trainer corrections and bulk actions, attendance and credit calculation, coordinator review and send-back, print/CSV reporting, audit history, source synchronization, maintenance controls, and release validation.

Later Supabase work is separate and is not presented as a completed production migration.

Normal check-in no longer requires handwriting interpretation. Source information resolves most identifiers, credit is calculated, and coordinators receive structured output.

Firsthand evidence indicates reporting can be prepared in minutes rather than more than an hour. Approximately 15 classes have been processed by estimate, with approximately one administrator, three coordinators, and ten trainers. A dashboard count of 21 active classes included future work and is not a completed-class count.

An unowned burden became a supported production workflow.

I continue to manage releases, troubleshoot production behavior, validate rules, improve performance and usability, and support the organization.

Google Apps Script and Google Sheets with maintained source data and role-aware web experiences. The case is about product judgment, validation, and operational ownership.