A proposal to build an AI-driven scheduling and matchmaking coordinator

Executive Summary

The club runs 6 courts and an active, level-organized player base, but court time still goes underused: some sessions sit below a good headcount while others fill up and generate waitlists — even when a similar session nearby has open spots. Today, closing that gap depends on someone manually watching the booking calendar and messaging players by hand, which doesn’t scale as the group grows.

This proposal is to design and build a Pickleball Court Coordinator Agent: a system that continuously watches the CourtReserve booking calendar, compares real bookings against ideal headcounts for each court configuration, and proactively reaches players through the level-based WhatsApp groups they already use — filling gaps before sessions go under-attended, and redirecting waitlisted players toward open capacity instead of leaving them stuck in a queue.

The goal is simple: more full courts, fewer wasted slots, less manual coordination work, and communication that feels helpful rather than like spam because it’s only ever sent to the players it’s actually relevant to.

The Problem Today

• Uneven fill rates: Because players self-organize through CourtReserve, some sessions land well below an ideal headcount while others overshoot and build a waitlist — often on the same day, sometimes even the same evening.
• Waitlisted demand goes to waste: A player waitlisted for a full session may have no idea that a similar session at their level has open spots an hour earlier or later, or on an adjacent court.
• Manual coordination doesn’t scale: Spotting these gaps and mismatches today depends on a person actively watching the calendar and messaging players individually — time-consuming, easy to miss, and dependent on one person’s availability.
• Communication structure is ad hoc: Players have been added manually into a single group, which makes it hard to send messages that are relevant to everyone receiving them without it feeling like noise.

Proposed Solution: The Coordinator Agent

The agent acts as an always-on coordinator layered on top of the tools already in use — it does not replace CourtReserve or require players to change how they book. It watches session-level data and matches supply (open court time) with demand (players who want to play) proactively, rather than waiting for a human to notice a gap.

Core capabilities

• Session monitoring: Pulls current headcount and waitlist depth for every court and time slot from CourtReserve.
• Level-aware communication: Players are grouped into WhatsApp groups by DUPR band (±0.5), so any message sent is already relevant to the band receiving it — this is what keeps the system from feeling like spam, by design rather than by clever targeting.
• Fill announcements: When a session sits below its ideal headcount, the agent drafts a targeted message naming the court, time, and number of open spots, for the matching band group.
• Waitlist rebalancing: When a session is full with a waitlist, the agent looks for a similar-time session in the same band (or the adjacent band as a fallback) that has open capacity, and offers waitlisted players the option to move there instead of continuing to wait.
• Respectful by design: Beyond group segmentation, the agent caps message frequency, batches multiple gaps into a single update where possible, and keeps every player in control of their own notifications.

How It Works

Data inputs

• Booking data: Reservations, rosters, and waitlist entries per court and time slot, read from CourtReserve.
• Player profile data: Weekly schedule availability, DUPR level, sex (where relevant to session type), light play-style notes to support compatible groupings, and WhatsApp group membership.

Note: CourtReserve offers an official API covering reservations, memberships, events, and reporting. The exact detail it exposes for waitlist entries and skill-level fields — and whether access is read-only or read/write — varies by account and should be confirmed directly with CourtReserve before build begins.

Capacity targets

These are the working targets used to decide when a session needs more players or has room to absorb a waitlisted one; they’re easy to adjust once real usage patterns are visible.

Configuration	Ideal headcount	Max before waitlist
Single court	5 players	6 players
Two courts	10 players	12 players

Fill and rebalance logic

For every upcoming session, the agent runs the same check:

Step	Action
1	Read current roster count and waitlist depth for the session.
2	Compare against the ideal headcount for that court configuration.
3a	If under ideal: identify the matching DUPR-band group and draft a fill announcement naming court, time, and spots remaining.
3b	If full with a waitlist: search same-band sessions near the same time for open capacity (adjacent band as fallback), and draft a redirect offer to the waitlisted players.
4	Hand the drafted message to a human to post (Phase 1), or post it directly once that step is automated (Phase 2).

Phased Rollout Plan

Building this in phases keeps risk low: the system earns trust on the read/monitoring side before it’s given any ability to act on its own.

Phase	What happens
Phase 0 — Foundation	Build the player database (schedule, DUPR level, contact, group membership); confirm the DUPR-band WhatsApp group structure; confirm the scope of CourtReserve API access available on the club’s plan.
Phase 1 — Assisted Coordination	The agent monitors CourtReserve and drafts fill and rebalance messages; a human coordinator reviews and posts them to the correct group. Lowest risk, validates the matching logic against real play patterns, and requires no change to how players book.
Phase 2 — Direct Messaging	Once the logic is proven, the agent can post directly into the WhatsApp groups. This is optional — Phase 1 already removes most of the manual burden, so the club may choose to keep a human posting messages indefinitely.
Phase 3 — Optional Auto-Booking	If write access to CourtReserve is available and the club is comfortable with it, the agent could move a waitlisted player into an open session directly rather than just alerting them. Worth considering only after Phases 1–2 prove out.

What Success Looks Like

• More sessions land at or near the ideal headcount instead of running under-filled.
• Waitlisted players get moved into open games instead of sitting idle.
• Meaningfully less manual time spent watching the calendar and messaging players by hand.
• Players experience the messages as helpful, not spammy, because they’re targeted by level and only sent when relevant.

Open Questions & Assumptions

• CourtReserve API scope: Exact access to waitlist detail, skill-level fields, and read vs. read/write permissions needs confirmation from the club’s CourtReserve account before development begins.
• Message delivery in Phase 2: No WhatsApp Business API integration is currently planned; if the club wants messages posted automatically rather than by a human, that decision — and its trade-offs — should be revisited at that stage.
• Capacity targets: 5 ideal / 6 max per court and 10 ideal / 12 max for two courts are the club’s current numbers; these are configurable if actual usage suggests different targets.
• Use of personality/play-style data: Used only to support compatible groupings within a band — never to exclude a player or drive who gets contacted.

Next Steps

If this direction looks right, the next step is a short discovery conversation to confirm CourtReserve’s API scope and finalize the player database fields, followed by building and piloting Phase 1 with one or two DUPR bands before expanding to the full club.