Automated Event Reporting Without Another Annual Subscription
I built an automated event reporting system that gives leadership timely registration and sponsorship updates without requiring someone to continually log into their CRM and pull reports. It turns data TCC was already receiving into useful, proactive updates for a volunteer leadership team.
Project Details
- My Role
- I owned the project end to end: product thinking, systems design, engineering, development, testing, and implementation. The work included defining what leadership actually needed to know, investigating the available integration paths, designing the reporting architecture, building the parser and ledger, and validating the output against GrowthZone.
- Duration
- 1 day
- Client
- Traffic Club of Chicago · 2026
The Brief
Committee leaders needed better visibility into the events they were responsible for, but getting that information required management to log into GrowthZone, run reports, and pass the results along. With roughly 20 events each year—and committee members balancing these responsibilities with full-time jobs—the goal was simple: deliver useful event status automatically, without requiring anyone to ask for it.
Approach
I started by investigating GrowthZone’s reporting, automation, integration, and API options. The built-in reports didn’t provide the level of detail leadership needed, and API access required an additional subscription, so I turned the registration notifications TCC already received into an integration layer. The system parses those notifications, reconciles registrations against an append-only ledger, and automatically sends reports one week, two days, and one day before each event.
Outcomes
Management no longer needs to repeatedly pull event reports just to keep committee leadership informed. Status updates now arrive automatically at useful decision points across roughly 20 events a year, giving busy committee members visibility without another system to check or another question they have to remember to ask. The system was validated against all seven upcoming events during development, including a live post-launch registration counted entirely through the new notification workflow.
Services
Tech Stack
Craft Notes
The most important design decision was choosing how the system should fail. Counts are deterministic rather than AI-generated, a failed event scrape stops the digest instead of risking a report with the wrong dates, and the ledger is intentionally append-only. When perfect synchronization isn’t possible, I’d rather expose a discrepancy that someone can investigate than silently lose a registration. There’s also a deliberate distinction between information that should travel and information that should stay protected. Sponsor organizations are surfaced directly because acknowledgement is part of the sponsorship relationship. Attendee names and employers stay behind restricted access—even though putting everything into one convenient email would have been easier.
Gallery
