I transformed an internal browser-automation script into a supervised Windows desktop application for enrollment, waitlist, and attendance work—making the workflow easier to use without automating away staff judgment.
Tennis schedulers had to move through the same enrollment screens each month, compare rosters and attendance, and decide how to handle students with waitlist or special-enrollment conditions. The original script automated part of that path, but it still depended on command-line knowledge and assumed a narrow input format.
The recent rebuild focused on the people operating the workflow. I added a guided interface, flexible imports, safer matching, focused audit modes, and explicit review points so staff can use the tool without giving up control of consequential decisions.
Contribution boundary
I identified the workflow from my scheduling role and built the automation. AVAC’s enrollment platform, customer records, and underlying business rules remain outside this case study, and the production implementation is private.
02 / Workflow
Automate the repeatable path
01Paste or import names
Staff can paste a list or import CSV, TXT, and PDF files through the desktop interface.
02Select classes and a task
The user chooses specific classes, the correct calendar month, and enrollment, waitlist, or attendance mode.
03Automate with review points
Selenium handles the repeatable path while ambiguous accounts, capacity limits, and exceptions remain visible to staff.
Workflow contextNo customer names or credentials displayed
03 / Recent rebuild
From internal script to staff-ready application
The latest version changes both how the tool is used and how it behaves when the source data is messy or a decision is unsafe to automate.
Added a guided desktop interface so staff do not need the command line.
Accepted names pasted directly or imported from CSV, TXT, and PDF files.
Added class selection plus separate enrollment, waitlist-audit, and attendance-audit modes.
Normalized and fuzzily matched differently formatted or slightly misspelled names.
Prompted the user when multiple accounts match instead of choosing one automatically.
Checked class capacity before attempting enrollment.
Flagged waitlisted students when a class has openings without changing enrollment data.
Flagged students with three or more consecutive absences for staff review.
Generated copy-ready contact details and editable waitlist email drafts.
Selected sessions by calendar month and prevented enrollment into outdated sessions.
Packaged the application as a portable Windows executable with no Python installation required.
04 / Verification
31 automated tests protect the decisions
The test suite covers input cleanup, session selection, name matching, capacity limits, ambiguous accounts, waitlist behavior, and attendance calculations. Browser-run results and staff review still provide the final operational check.
Automated coverage31 tests passing
Core rules are checked independently of the live website.
Human reviewAmbiguity stops
Multiple matches, waitlists, absences, and special cases are surfaced instead of guessed.
Capacity and timeUnsafe actions blocked
Full classes and outdated sessions are rejected before enrollment is attempted.
05 / Privacy review
Operational data stays outside version control
This was an internal workflow-automation project built for authorized tennis staff. During a privacy review, I found that historical operational data had been retained in the repository’s Git history. I made the repository private, removed the data from active history, and initiated GitHub’s permanent removal process. The case study now uses only synthetic examples, and the production implementation remains private to protect member information.
Privacy boundaries
Treat staff workflows and member information as private by default, including historical revisions and generated artifacts.
Human review
Keep staff in control whenever attendance, waitlists, special cases, or failures require judgment.
Environment-based credentials
Load secrets from the runtime environment and provide only synthetic configuration examples.
Data lifecycle
Keep operational exports, logs, rosters, and other real records outside version control.
06 / What I learned
Reliable automation is a product-design problem
This project taught me that reliable automation is about more than making browser actions happen. I had to translate a real operational process into clear software rules while preserving human judgment wherever a wrong decision could affect a student or staff member.
Design for people
Move complexity behind a guided interface and make review points clear to staff who did not build the tool.
Separate concerns
Keep interface, business-rule, and browser-automation logic independent so each layer can be understood and tested.
Expect imperfect data
Clean and reconcile names from PDFs, spreadsheets, text files, and web pages without hiding uncertainty.
Handle edge cases deliberately
Treat duplicate accounts, capacity limits, waitlists, and attendance exceptions as primary product behavior.
Build resilient automation
Account for changing and sometimes unpredictable web interfaces while keeping failures visible.
Ship the whole product
Packaging, privacy, credentials, testing, and error reporting are core features—not cleanup after the code works.
07 / Result
A more capable tool that remains supervised
The assistant now gives staff one accessible place to prepare inputs, choose the exact task, review exceptions, and complete routine work. The portable executable makes the workflow easier to share internally, while privacy boundaries and human-review checkpoints keep the automation appropriately limited.
Exact time saved, run counts, and error percentages are not documented here, so this case study does not claim them. The evidence is the working desktop workflow, its 31 passing tests, sanitized interface, and explicit manual-review paths.
