SaaS
AI-assisted tournament scheduler
This project helps youth sports operators create tournament schedules far faster by combining LLM-based natural-language constraint capture with deterministic optimization. Sonnet translates operator inputs into typed constraints, OR-Tools generates the schedule, and lighter-weight models explain decisions and validate edits in plain English. The workflow preserves human control through a wizard-style interface rather than a black-box chatbot.
The problem
Youth sports operators run their tournaments off spreadsheets. After registration closes, a matchup generator spits out 170+ games with no times or fields, and a single tournament director hand-places every one across divisions competing for the same fields — holding 10-15 rules in their head the whole way. The result is a 15-20 hour, multi-day grind. The mental load is brutal once multiple divisions fight over shared fields, nice-to-haves like even rest and good slots for marquee matchups quietly fall off, and fixing one conflict often breaks another. There's no second set of eyes, and the cost of a published mistake is high.
The solution
The AI-Assisted Tournament Scheduler pairs natural-language rule capture with deterministic optimization, cutting first-draft scheduling from a full day to under 60 minutes. Operators answer six plain-English questions; the system turns each answer into structured constraints, solves the schedule, and explains what it did. Crucially, the scheduling itself is not an AI job — that's a math problem handled by a solver. The design keeps the operator in control through a step-by-step wizard rather than a black-box chatbot, directly answering the roughly 90% of operators who want their hands on the wheel. It's built to live inside LeagueApps, which already holds the teams, coaches, fields, and divisions.
How it works
The workflow is a hybrid: the LLM handles language at both ends and a real solver does the placing in the middle. Sonnet reads each operator answer and extracts a fixed set of typed constraints — time windows, rest, field changeover, slot preferences, prime slots — each tagged hard or soft with a weight, returned as clean structured data through a tool rather than free text. OR-Tools then places every game across all divisions in seconds, because hard rules must be satisfied every time. Haiku writes a plain-English summary and flags items to check, and validates edits in real time as the operator moves games on a visual calendar. Physics-level rules — a coach can't be in two places, a game can't go on a wrong-sized field — are always enforced and never shown to the model as a choice. Constraint intake was tuned across four rounds from 9/27 to 27/27 exact match, with precision and recall reaching 1.00.
Who it's for
The buyers are club directors, league admins, and tournament operators — the decision-makers running youth sports organizations on a platform like LeagueApps. The primary user is the tournament director or scheduler who owns getting games onto the calendar. The most valuable users are big multi-program operators and tournament hosts, where payments volume and retention concentrate. It's a B2B and B2B2C model: operators buy it, and they in turn serve the families, players, and coaches who depend on a clean schedule.
Why it matters
Youth sports is a $40B business that keeps growing, with operators finally moving off spreadsheets onto real platforms. The scheduling gap between a matchup generator and a published calendar is exactly where a full day of manual work disappears. Collapsing that to under an hour of structured work drives stickiness and retention, and closes a competitive gap on the tournament side against tools like TourneyMachine and Exposure Events. Rollout is staged — re-running past tournaments first, then a small pilot with trusted, tech-savvy tournament directors — with every operator action logged as the foundation for a system that learns each operator's preferences over time.
The workflow
The PRD
| PRODUCT FACULTY — AI PRODUCT REQUIREMENTS DOCUMENT (PRD) TEMPLATE Version 1.0 | ||||||
|---|---|---|---|---|---|---|
| Your Name: | Gautam Chowdhry | |||||
| Your Product: | AI Assisted Tournament Scheduler | |||||
| Your Industry: | B2B Vertical SaaS - Youth Sports | |||||
| Date: | 05.01.2026 | |||||
| 4D Method | AI PRD | Instructor Feedback | ||||
| Phase | Activity | Theme | Topic | Key Question(s) | Your Response Include external links to visuals/prototypes as required. | |
| DISCOVERY | Understand your market, business, product & user context | Business Value Map | Market Attractiveness | What industry is your business in? (ie Financial services, Healthcare, Education, etc)? | B2B Vertical SaaS for Youth Sports. LeagueApps is the platform youth sports operators run their whole operation on: registration, payments, scheduling, and comms, all in one place. Our buyers are the clubs, leagues, and tournament organizers and operators. | Please leave this area blank. This space is for the Instructor to provide you with feedback. |
| What are the key challenges (headwinds) and opportunities (tailwinds) impacting growth in your industry? Who are the key competitors? | Tailwinds: youth sports keeps growing, more money flows in every year, and operators are finally moving off spreadsheets onto real platforms. There's also consolidation happening in the industry, making the need for a true platform even more important than before. Headwinds: a lot of these operators set in their ways — spreadsheet loyalty is real. The business is seasonal and the smaller end is price-sensitive. Competitors: SportsEngine, Stack Sports (Blue Sombrero/GotSport), TeamSnap, Playmetrics, Demosphere — and on the tournament side specifically, TourneyMachine and Exposure Events. | |||||
| What is the projected growth rate of your target market segment over the next 3-5 years? | Youth Sports is a $40B business. | |||||
| Business Model | What growth stage is your business currently in (e.g., startup, scale-up, mature)? | Established and scaling. | ||||
| How does your business make money? What do they sell? What is your primary revenue model (e.g., subscription, freemium, licensing, marketplace, transactional, etc?) | B2B SaaS, subscription and transacational revenue. | |||||
| Who is your primary customer base (B2B, B2C, B2B2C)? | B2B and B2B2C — we sell to operators, and they turn around and serve families, players, and coaches. | |||||
| Differentiators | What are the key differentiators for your company? | We go deep in one space — youth sports — instead of being a generic tool that does a little of everything. Because registration, payments, scheduling, and comms all live on one platform sharing the same data, things just connect. That's the real edge here: an AI scheduler already knows the teams, coaches, fields, and divisions because all of that already lives in LeagueApps. A standalone tool would make you re-enter all of it. | ||||
| Feature Value Map (IMPORTANT NOTE: This section is only relevant if you are working on enhancing an existing product. It does not apply if you are developing a new product from 0 to 1.) | Customers | Who are the customers (ie buyers) of your product? | The people who buy it — club directors, league admins, and tournament operators. The decision-makers running the org. | |||
| End Users | Who are the end-users of your product? Which users are the most revenue-generating / revenue-impacting for your company? What are their goals, roles, and context? | The operator running the show is the main user — for this project, specifically the tournament director or scheduler. The most valuable users are the big multi-program operators and tournament hosts, since that's where the payments volume and the retention really sit. | ||||
| Current Products / Services | If you are a Product-led business: What are the core features of your product, and how do they address user needs? If you are a Service-led business: What are the key services you offer to customers? | Registration, payments, scheduling (including the tournament matchup generator and the calendar), communications, and operator websites. The matchup generator already creates the pool-play pairings — getting those games onto the calendar is exactly the gap this project fills. | ||||
| User Value Map | Target Persona | Who is your AI product / feature for? (Internal users, external users, an influencer, a buyer, etc) | The tournament director or scheduler who actually owns getting games onto the calendar — the person who'd otherwise have to spend 15+ ours on getting to th first draft of a schedule. | |||
| Journey Map (current-state) | What is the typical journey for your target persona when they are using your product / service, focusing on their ideal experience (happy path) as they interact with your product? | Registration closes. The operator runs the matchup generator and gets back 170+ games with no times or fields on them. Then they open a spreadsheet — usually not even the platform — and start hand-placing every single game across all the divisions sharing the same fields, holding 10-15 rules in their head the whole time. A full day later they've got a draft. Someone sanity-checks it and catches a problem or two. Fixing those sometimes breaks something else. They publish. A few hours later a parent or coach spots a conflict they missed, so they pull it down, fix it, re-send, and re-publish. | ||||
| Pain-points | Where does the user experience friction, obstacles, or unmet needs throughout the journey? Identify which pain-points are most frequent and severe? | 1) The mental load is brutal once you've got multiple divisions fighting over the same fields — that's the worst of it. 2) It eats a whole day, and that day is competing with everything else happening before a tournament. 3) The nice-to-have stuff — even rest, balanced fields, good slots for the big matchups, morning games for travel teams — quietly falls off when you're under the gun. 4) Fix one thing and you break another, sometimes in a different division entirely. 5) There's no second set of eyes — it's one person, and the cost of a mistake is high. | ||||
| AI Opportunities | From your list of pain points, identify those that can effectively be addressed using Generative AI. Remember, this project focuses on leveraging LLM-powered AI to solve your target persona's pain points. Rank these pain points starting with the most severe and frequently occurring first. | 1) Constraint intake — taking what an operator says in plain English and turning it into structured rules the system can use. This is the biggest win and goes right at the mental-load problem. 2) Explaining the schedule — turning the solver's output into a plain summary the operator can actually trust and check. That's the second set of eyes they never had. 3) Checking edits in real time as they move things around. One thing I want to be clear about: the actual scheduling is NOT an AI job — that's a math problem, and a solver handles it. | ||||
| Develop an AI Solution Hypothesis | AI Solution Hypothesis | Diverge | Ideate potential solutions to address your AI-solvable pain points. Focus on generating a high quantity of ideas rather than evaluating their quality at this stage. | Ideas on the table: a full-auto magic button that just spits out a schedule; an LLM that places the games itself; a chat copilot that suggests moves; a hybrid where the LLM gathers the rules and a solver does the placing; a library of reusable rule templates operators clone each season; or a tool that just cleans up the spreadsheet they already use. | ||
| Converge | Rank your ideated solutions based on impact and feasibility. Identify your top three AI solutions, and clearly select the one you'll focus on for your project. | Scoring those on impact vs. how doable they are, the winner is the hybrid: let the LLM handle the language at both ends (gathering rules, explaining the result) and let a real solver (OR-Tools) do the actual scheduling in the middle. Letting an LLM place the games looks impressive but doesn't hold up — it'll quietly break rules, and one missed conflict kills trust in the whole thing. The magic button also fights what we heard in discovery: about 90% of operators want their hands on the wheel, not a black box. The hybrid gives you both — a schedule you can prove is valid, and an operator who stays in control. | ||||
| DESIGN | Define Target State Workflow | UX Flows & Wireframes Suggested Tool: Excalidraw | Workflow (future) | Assuming your product or feature works as desired, what is the target state workflow? | Registration closes, the operator exports the matchups from as a file (about 170 games, no times or fields yet) and drops it into the tool. They answer six quick questions in plain English — things like what hours games can run, how much rest between games, travel teams, the big matchups, field preferences, and anything else. Sonnet turns each answer into structured rules and shows them back in plain English to confirm. Once they sign off, the solver places every game across all the divisions in a few seconds. Haiku writes up what it did and flags anything worth a look. The operator tweaks a few things on a visual calendar — with instant feedback on each move — confirms, and imports it back into the main system (either by CSV or API). Whole thing: under 60 minutes instead of a a 15-20 hour, multi-day project. In the future, this is an integrated workflow, that launched a "Schdedule Builder Wizards" in a full screen modal. | Please leave this area blank. This space is for the Instructor to provide you with feedback. |
| Build Wireframes | Wireframes | How will users navigate through your AI solution? What are the key steps and decision points? What information will be displayed at each stage? What specific UI elements are needed on each screen? How will the layout accommodate AI features? | It's a simple four-step flow built in Streamlit. Config: load the matchups, see a quick summary (divisions, teams, games, fields). Intake: one question per screen, a text box to answer, and a running list of the rules it's picking up — the key moment is confirming that list before anything gets scheduled. Review: the screen splits — calendar grid on the left, color-coded by division, and the plain-English explanation on the right with the items to check. Edit: click a game, click where you want it, and you get an instant message (green if it's fine, red if it causes a conflict). The whole point of the layout is to keep the AI's output right next to the thing it's describing, so the operator never has to go hunting to trust it. | |||
| Develop Prototype to showcase AI interactions | Prototype Screens Suggested Tool: lovable.dev | What aspects of the AI solution will you demonstrate in your prototype? How will the AI inputs, processing, and outputs be presented visually to users? Which features are essential for launch? What can be left for later releases? | The prototype shows the three places AI shows up: 1) intake — type a sentence, watch the rules appear; 2) explanation — the schedule comes back with a plain-English writeup and a here-are-three-things-to-check; 3) edit-checking — move a game and get an instant read on whether it works. You see the input as plain language, the processing as the confirm-the-rules step and a quick solve, and the output as the color-coded grid plus the writeup. Must-have for launch: the full four-step flow working end to end on one tournament. Can wait: learning from old spreadsheets, true drag-and-drop, the usage logging, and learning an operator's preferences over time. | |||
| Initial Prompt Design | Master Prompt [Initial Design] | Create an initial master prompt. Consider the following: What tone or personality should the AI use? How should user input and system instructions be structured for maximum clarity? What system instruction will govern the AI's behavior? What examples might improve performance? How will you format outputs for consistency? | Setup: you're a scheduling assistant for a youth soccer tournament — talk like an operator (pool play, bracket, seed, rest), skip the AI/tech jargon. The job is narrow: take the operator's answer to one specific question and pull out the rules. It's paired with a per-question prompt that feeds in the question, their answer, and the tournament context. To keep it reliable, the model doesn't free-write — it returns a fixed set of rule types (time windows, rest, field changeover, slot preferences, field assignments, prime slots, and a catch-all), each tagged hard or soft with a weight. A few simple rules guide it: no games before 9am is hard; prefer or try to is soft; must/never/no is hard; convert times to 24-hour; when it's unclear, default to soft; and if there's nothing to pull out, return nothing. Output is clean structured data that feeds straight into the solver. | |||
| Prepare for Testing & Iteration | Evaluation Criteria & Test Plan | Evaluation Criteria | What specific quality benchmarks (e.g., clarity, relevance, tone, accuracy, SEO, hallucination avoidance) will define “good” output? | For the intake: is it pulling the right rules (precision), is it catching all of them (recall), is it making any up (false positives), is it getting hard-vs-soft right, and does it flag genuinely vague answers instead of guessing. For the solver: every hard rule has to be satisfied, full stop, and the soft stuff should score above 85%. For the explanation: can someone read it and know what to check first, and does it make them more confident or less. For the edit-checker: is the validity call correct and is the message clear. | ||
| Example Cases | What specific example use cases, edge cases, and negative cases should be covered by test prompts and outputs? | Typical: no games before 9am, last games done by 8pm Friday — hard time limits; 90 minutes rest, except U10 Boys can do 75 — a rest rule with an exception for one division. Edge: a 6-team pool that really runs as two pools of three; a coach with six teams across three age groups (that's real); one answer that contains several rules at once. Negative: vague (morning — before noon or before 10?) — ask; contradictory (a rest minimum that won't fit the hours they gave) — flag it; empty (no preference) — return nothing; off-topic (can you book hotels?) — ignore it. | ||||
| DEVELOP | AI Model Selection & Justification | AI Model Selection & Justification | Which AI model is best suited for your solution and why? What capabilities and limitations does it have? How will it integrate with your product? | I'm using different Claude models for different jobs, based on what each part actually needs. The hard thinking — turning what an operator types into structured rules, catching when they're vague, reading between the lines — goes to Sonnet. The lighter work — writing up what the schedule did and checking edits as they're made — goes to Haiku, which is faster and cheaper and just as good at that. The actual scheduling doesn't use a model at all; that's OR-Tools, because the math has to be right every time and I'm not going to let a model quietly get it wrong. I also ran the intake task on Haiku and Opus against the hardest inputs so I can show why Sonnet's the right call, not just claim it. | Please leave this area blank. This space is for the Instructor to provide you with feedback. | |
| Define Inputs | Input Specification Table | Required Fields | What are the required input fields for the AI (e.g., title, description, keywords, tone)? Indicate format, source, requirement. | What the AI needs every time: the operator's plain-English answer to the question (text, from the operator); the question being asked (text, from the system); and the tournament context — name, divisions, teams, coaches, fields and their formats (structured data, pulled from the LeagueApps export). | ||
| Optional Fields | Are there any optional or user-customizable fields? How do they impact the AI’s output? | Nice-to-haves: any team-level special requests and home region from the registration form (treated as soft rules with a weight); and, later on, old tournament spreadsheets the operator can upload so the system can suggest rules from past patterns. None of these are required — the schedule still runs without them. | ||||
| Define Good Output | Output Evaluation Checklist | Objective Criteria | What criteria will you use to judge output as “good”? (e.g., structure, use of keywords, tone, factuality, relevance) | Is the output clean, valid structured data in the right shape; did it pick the right rule type; did it get hard-vs-soft right; are times in 24-hour format; is the scope right (whole tournament, division, pool, or team); did it avoid making anything up; and does it correctly return nothing when there's nothing to pull out. | ||
| Subjective Criteria | Are there any criteria that require human judgment or qualitative assessment? | Did it actually get what the operator meant, not just match keywords; was its hard-vs-soft guess reasonable when the wording was fuzzy; were its follow-up questions actually helpful or just nitpicky; and for the explanations, does it read like something an experienced tournament director would trust. | ||||
| Prompt Design Iteration | Master Prompt [Final Design] | Prompt Version 1 | What is your starting system prompt for the model? What variations will you test? What techniques will you use to optimize performance? List initial instructions, persona, inputs, and constraints. | A per-question prompt that sets up the youth-soccer-tournament-assistant voice, lists the rule types it can use, and gives it the simple guidelines (must/never = hard, prefer/try = soft, convert to 24-hour, default to soft when unclear, return nothing if there's nothing there). It hands back structured data through a fixed tool rather than free-writing. | ||
| Prompt Iterations | If revised, what changes did you make and why? How do you track and record prompt evolution? | The big change: I started with one big prompt asking the operator to dump everything in a paragraph, and switched to asking six focused questions and pulling rules from each one separately. That made each call simpler and more reliable, made it way easier to test, and made it easier on the operator — the system asks instead of making them remember everything. After that I tuned the hard-vs-soft defaults, added handling for division-specific exceptions (like the U10 rest carve-out), and worked through how coach conflicts get treated. All the prompts live in the repo so I can track how they've changed. | ||||
| Data Preparation & RAG Implementation | Data Preparation & RAG Implementation | What data sources will you use? How will you prepare data for model training or evaluation? (e.g., cleaning, structuring). For RAG: How will you chunk, embed, retrieve relevant information? | No RAG here, and that's on purpose — there's nothing to retrieve. The scheduling is done by the solver, and everything the model needs to know (teams, coaches, fields, divisions) just gets handed to it straight from the tournament data. For data, I built a mock tournament off a real one we ran — 16 divisions, 227 teams, 368 games, 3 venues — kept the real structure and the messy edge cases (like the coach running six teams) but swapped in fake names so no real data lands in the project. My test inputs are real-sounding constraint statements I hand-labeled with the right answer. | |||
| Create Evaluation Set | Example Input/Output Data for Testing | Typical Examples | What are the most common inputs and expected outputs? Use real data if possible. | No games before 9am, last games done by 8pm Friday — two hard time limits. 90 minutes rest, except U10 Boys can do 75 — a tournament-wide rest rule plus an exception just for U10 Boys. | ||
| Edge Cases & Negative Cases | What examples test the AI’s limits? (e.g., missing data, ambiguous input, out-of-domain) | Edge: a 6-team pool that runs as two pools of three; the coach with six teams placed with no overlaps; one answer that has several rules packed into it. Negative: vague (morning — before noon or before 10?) — ask before moving on; contradictory (a rest minimum that won't fit the hours given) — flag the conflict; empty (no preference) — return nothing; off-topic (can you book hotels?) — ignore it. | ||||
| Test Example Data & Review Results | Manual Review | Run your input data with the prompt. How did your output perform in manual review? Which examples failed which criteria, and why? | I built a 27-case test fixture for C1 (constraint intake), stratified across the six wizard questions and four categories per question (simple, complex, scoped, adversarial). The baseline run scored 9 of 27 exact (33%), with 18 failures grouped into four patterns. The biggest was hard-vs-soft mislabeling — the original system prompt didn't map "should" to any severity, so Sonnet defaulted it to hard, failing cases like "U14 Boys should play in the morning" (extracted hard, expected soft) and "Teams should have at least 3 hours rest." The second was invented rules: Sonnet fabricated sublocation IDs ("crestwood_sports_complex" instead of the canonical "crestwood"), invented an out-of-enum game_type ("pool_matchup" — not in the schema), and even fabricated a rest_minimum from the word "Standard" in a dismissive answer that should have returned empty. The third was scope escalation — pool-scoped constraints dropped their division_id, and category-style team references collapsed up to scope=tournament instead of scope=team. The fourth — the most interesting — was a schema-level mismatch: Q3 was framed around travel preferences ("Sacramento teams want morning slots"), but the demo data has no city or region on teams, so the answer couldn't map to anything actionable. That failure forced a product call — reframe Q3 to team-specific time restrictions and extend the TimeWindowConstraint schema with team_id and pool_id fields — which jumped Q3 from 1/4 to 4/4 exact. I iterated the prompts in four targeted rounds, each closing one pattern, landing at 27/27 exact (100%). | |||
| Automated Evaluation | What pass/fail rate or scores did the AI achieve on core criteria? | Across the four iteration rounds, the eval tracked exact-match pass rate (9/27 → 17/27 → 19/27 → 24/27 → 27/27), precision (0.15 → 1.00), recall (0.18 → 1.00), and false-positive rate (0.85 → 0.00). Adversarial detection — Sonnet correctly returning no constraints on dismissive answers like "No preferences," "Standard," or "Whatever the system thinks" — landed at 6 of 6 cases after the empty-extraction rules were added to the system prompt in Round 1. The C1 eval is Sonnet-only; I scoped the model A/B across Haiku, Sonnet, and Opus as Phase 2 work, but the model-comparison evidence appears in the C3 (explanation generator) eval, which is structured as a Haiku-vs-Sonnet A/B with Sonnet acting as the judge against a four-dimension trust rubric (clarity, completeness, actionability, accuracy). In that eval, Haiku matched Sonnet on fact coverage (95% each) and reached 90% of Sonnet's trust score, validating Haiku as the production choice for templated summarization at roughly one-tenth the cost. | ||||
| Handle Edge Cases & Iterate | Edge Case Identification | What edge cases did you identify in testing or real usage? | Multiple pool sizes. 4 is easy, but 6 and 10 are also very possible and have unique workflows; coaches with multiple teams; vague time wording; rules that contradict each other; division-specific exceptions; and different field sizes for different age groups. | |||
| Updates & Adjustments | What prompt or system adjustments have you made based on failures, feedback, or edge case observations? | Split intake into one question at a time so answers don't bleed together; set clear defaults for hard vs. soft; added division-level exceptions; and built a two-tier model so the laws-of-physics stuff (a coach can't be in two places at once, a game can't go on a field that's the wrong size) is just always enforced and never even shown to the model as a choice — while the operator's preferences carry their own hard/soft tag and weight. | ||||
| Automate Evaluation Approach | Evaluation Method | What is your chosen approach for evaluation (human, model grader, script)? How will you scale testing to diverse/large test sets? | Mostly scripts (pytest) checking against answers I labeled by hand — that covers the intake (precision/recall) and the solver (the hard rules are pass/fail by nature, and the soft score is just math). For the explanations, I read a small batch myself and rate them on a simple 1-5 trust scale, maybe with a model helping grade. | |||
| Evaluation Frequency | How often will you re-run evaluations for new data, new prompts, or post-launch monitoring? | Re-run the relevant tests every time I change a prompt or the data shape, and do a full pass before recording the demo. Down the road this becomes a regression check on every prompt change plus keeping an eye on new tournaments as they come through. | ||||
| DEPLOY | Finalize Launch & Rollout Plan | Operational Readiness Checklist | Technical Readiness | Is infra (APIs, databases, rate limits, monitoring, rollback) tested and documented? | For the POC: the whole flow runs end to end on a fixed mock dataset, and the write-back uses' existing bulk update — either CSV import or API Create. | Please leave this area blank. This space is for the Instructor to provide you with feedback. |
| Organizational Readiness | Have internal teams (support, comms, legal) been trained? Is documentation complete? | Right now it's mainly me. I've done an end to end demo with one of our tournament operators, plan to do more and pilot this with a small set of friendly customers. | ||||
| Launch & Rollout Strategy | Launch Approach | What is your launch approach? Pilot, AB test, or all users—who gets access and when? | Roll it out in stages. First, prove it by re-running a couple of past tournaments (no live risk). Then a small pilot with a few tournament directors I trust on real upcoming events. Then open it up more broadly. I'm deliberately going after the customers that I know personally and who are tech savy and interesed in trying out something new, and giving real feedback. | |||
| Scale Readiness | How will you ensure readiness for scale? How will you monitor initial volume and scale up? | The solver chews through the full 16-division, 368-game tournament in minutes, so raw compute isn't the worry — it's the volume of model calls and handling them at once. Pilot volume is low (tournaments come and go, they're not constant), so it's easy to watch early on, and I'll scale up as operators get comfortable and the number of edits stays low. | ||||
| Go-to-Market Plan | Marketing / Training Assets | What assets (FAQ, demo, guides) will you prepare for external communication/marketing? | A short demo video (which doubles as the internal pitch), a one-pager for our sales/GTM folks, and a quick-start guide for operators. The hook is the one everybody gets: 12-15 hours of hand-scheduling cut down to under and hour of structured work. Purposly using a step by step wizards vs. a chat bot to keep the user on task, and make them feel like they are part of the process and in control. | |||
| Stakeholder / Internal Comms | How will you communicate launch plans, progress, and outcomes internally? | Demo it internally to Head of Product and tournament scheduler SME before to get buy-in. Will need fine tuning and polish and official roadmap investment in order for use to scale. | ||||
| Confirm Legal, Privacy & Risk Protocols | Data & Privacy | How do you handle and protect user data, including storage, privacy, and compliance? | Everything I'm building on is fully anonymized — real tournament, venue, team, and coach names and emails never go into the repo, the prompts, or anything the tool generates. The files with real info stay on my machine and out of version control, and the mock data keeps the structure but uses made-up names. One note for production: I'm using coach email as the ID for now; that'd switch to the platform's user ID once it's integrated. What goes to the model is just scheduling info, not sensitive personal data — but for a real launch we'd document exactly what's sent and check it against LeagueApps' data policy. | |||
| Policy & Compliance | Are content moderation, legal, and audit processes in place? Are you compliant with regulations needed for your domain? | Nothing external to worry about for the POC — it's internal data and there's no sensitive kid info beyond basic team/coach scheduling details. For a real launch I'd want to confirm the model provider's data terms are fine by LeagueApps' standards, keep a record of what the AI suggested vs. what the operator actually approved (the usage log already gives us that), and make it dead clear the operator owns the final schedule — nothing publishes on its own. | ||||
| Define Success Metrics | Success Metrics | User/Business Metrics | What user metrics will indicate success? What business metrics will demonstrate value? | On the user side: under 60minutes start to finish (vs. a full day today), fewer than ~10 manual fixes after the AI places it (that's the best signal the output's good), and a 4-out-of-5-or-better on would you use this instead of doing it by hand next time. On the business side: scheduling driving stickiness and retention, and tournament scheduling closing a gap we have against competitors. | ||
| AI Metrics | How will you measure AI performance and accuracy? | Intake: is it pulling the right rules and not inventing any, and is it catching vague answers. Solver: every hard rule satisfied (non-negotiable), soft stuff above 85%. Explanation: a 1-5 trust rating from people who read it. Plus the model comparison (Haiku vs. Sonnet vs. Opus) to back up why I picked what I picked. | ||||
| Monitor, Iterate & Improve | User Support & Feedback Plan | Support Channels | Where can users get support? Is escalation and ownership clear? | I will personally be the support during the pilot to learn of the successes and failures. At Scale, we have support team that will need to be trained up on how this tool works. | ||
| Feedback Workflow | How do you gather, triage, and act on feedback and bugs? How are critical issues prioritized and communicated? | Get feedback straight from tournament directors after each event (a quick survey plus the would-you-use-it-again question), and lean on the usage log to see where operators overrode the AI — what rules they rejected, what they moved, what tradeoffs they picked. That tells me what to fix first. Anything where a hard conflict slips into a published schedule is top priority, no question. | ||||
| Monitoring & Continuous Improvement | Monitoring Approach | What monitoring/logging is in place to spot operational/AI issues post-launch? | Every operator action gets logged as structured data per run — which rules they accepted or rejected, every move, solve time, the satisfaction report, total time, total edits. In the POC it's just instrumentation, it doesn't change anything. In production it becomes how I keep an eye on solve performance, how much editing people are doing, and whether the rule-extraction quality is slipping. | |||
| Ongoing Improvement | How will you collect learnings, review performance, and update your system continuously post-launch? | All that logged data is the foundation for the next phase: learning each operator's preferences. Once someone's run a few tournaments, the system can start leaning toward the rules they usually accept and weighting things the way they tend to. Plus regression tests on every prompt or data change. That's where the it-gets-smarter-the-more-you-use-it part actually becomes real for the operator. | ||||
