
Christine James
Senior Product ManagerBuilding Fair Systems for Communities That Run on Trust
How I designed and built the automation infrastructure behind a Reddit and Discord community doing $1.5M in annual product volume - with 8 moderators and a commitment to fairness at every step.
The Context
I help run a large Reddit and Discord community built around a high-volume raffle system. The numbers: over 10,000 members, approximately $1,500,000 in annual product volume (Pokémon cards), and a moderation team of 8 people (including me) responsible for keeping it all running fairly and consistently. At that scale, manual processes don't just slow you down. They introduce inconsistency, and inconsistency erodes trust. In a community where trust is the entire foundation, that's an existential problem.
I decided to build something better.
Act 1 - The Problem
The community processes 130-180 raffle requests per month. Before automation, every one of those required manual moderator handling: reviewing submissions, making approval decisions, communicating outcomes, managing schedule conflicts, and handling swaps when hosts needed to move their time slots. Eight moderators, no audit trail, no consistency guarantees, and a community of thousands watching every decision.
The pain points were real on both sides. Moderators were burning out on repetitive work. Community members were waiting on humans for things that didn't need humans. And because decisions weren't systematically documented, there was no way to demonstrate fairness when someone challenged a call.
The insight: this wasn't a moderation problem. It was a systems design problem.
Act 2 - The Architecture
The stack I built:
Google Forms as the user-facing entrypoint. Community members schedule raffle requests through a structured Google Form - it's the primary interface they interact with, designed to capture all the information the moderation workflow needs upfront. Clean input at the front of the funnel means cleaner decisions downstream and fewer back-and-forth clarification requests from the mod team.
Google Sheets as source of truth. Form submissions feed directly into a structured mod audit sheet and a community-viewable sheet that track every raffle request, outcome, host history, and moderator action. Every row is timestamped with created date, last modified date, and last acting user. Historical rows are protected and immutable - the audit trail is permanent and tamper-resistant. But Sheets isn't just storage, it's where the majority of the automation lives. I built an extensive Apps Script layer directly into the spreadsheet: trigger-based workflows that fire on edits, auto-populate fields, enforce data integrity rules, calculate host statistics, route requests based on their status, and flag edge cases for human review. The result is a system where a moderator opening the mod audit sheet sees clean, processed, actionable data - not a raw dump of form submissions they have to manually interpret. And a community member viewing the community sheet sees the upcoming schedule with only the information they care about.
Apps Script automation. The trigger-based system (commonOnEdit_ pattern) is the connective tissue between the Google Form, the Sheets data layer, and Gengar. It handles the logic that keeps all three in sync - routing requests, updating statuses, and ensuring that what the Discord bot sees always reflects the current state of the source of truth.
Gengar: the Discord bot. A Node/Express bot hosted on Render, using a Google service account for Sheets API access. Gengar posts structured raffle embeds to Discord with formatted details - raffle name, host, pricing, schedule slot, host history - and surfaces Approve/Reject/Needs Review buttons for moderators. Rejections open a modal requiring structured notes, so every negative decision is documented with a reason. Mod-only permission gating, channel allowlists, and a POST_SHARED_SECRET ensure the system can't be manipulated by community members. Production and staging environments are fully separated - different Discord servers, channels, sheets, and credentials - so changes can be tested safely before touching the live community.
Act 3 - The Swap Workflow
The decision I'm most proud of is the swap workflow - and it's a good example of how the best product solutions solve problems on both sides of a system simultaneously.
Before automation, when a host needed to move their scheduled time slot, a moderator had to manually handle the swap: find the affected rows, update the schedule, communicate the change, and log it. It was tedious, error-prone, and created a queue that the moderation team resented and the community noticed.
I built a fully automated swap workflow, the first end-to-end automated process in the system. Hosts submit swap requests through a structured channel. The system validates eligibility, executes the swap in the source of truth, logs it, and posts confirmation. No moderator intervention required for standard cases.
The mod team got hours back. The community got faster resolution. And because the workflow is structured and logged, every swap is auditable. It was appreciated by everyone immediately, which is rare for a system change.
What It Looks Like at Scale
•60-80 detailed scheduled requests per month requiring human review
•70-100 fully automated requests per month handled without moderator involvement
•8 moderators maintaining continuity of operations for 10,000+ members and $1.5M in annual volume
•Full audit trail for every decision, permanent and immutable
•Staging/production separation for safe iteration
What This Shows
The skills that make a good research platform PM are the same ones that make good community infrastructure: governance thinking, edge case obsession, fairness by design, and deep respect for the people depending on your system to be consistent. The domain is different. The work is the same.