An AI court coordinator watches your existing booking calendar (e.g., CourtReserve), compares real-time headcounts against ideal capacity for each session, and proactively messages the right group of players — organized by skill level — when a session needs more players or when a full session’s waitlist could be redirected to an open slot elsewhere. It doesn’t replace your booking system or require players to change how they sign up; it fills the coordination gap that no booking calendar handles on its own.

The problem: full calendars, empty courts

A facility can have an active player base and a working booking system and still leave court time on the table. It happens in a very specific, very fixable pattern:

• Some sessions land below a good headcount — court time goes underused, and the players who did show up get a worse game (not enough people for solid doubles rotation).
• Other sessions overfill and build a waitlist, sometimes on the very same evening a different court sits half-empty.
• Someone has to notice both of these things happening and manually message players to fix it — which works until the group gets big enough that one person can’t watch the whole calendar anymore.

What an AI coordinator agent actually does

The design that solves this has four moving parts, and none of them require replacing tools the facility already uses:

1. It reads the calendar. Using the booking platform’s API (CourtReserve, in this case), the agent pulls current roster counts and waitlist depth for every court and time slot.
2. It knows what “full enough” means. Capacity isn’t binary — a single court plays best with 5 players (6 is the max before people start waiting), and two courts run well at 10 (12 max). The agent compares real numbers against these targets, not just “booked vs. not booked.”
3. It talks to the right people, not everyone. Players are organized into groups by skill level (DUPR band, ±0.5) — a structure players opt into because it’s how they’d want to find games anyway. This is the detail that keeps the system from feeling like spam: a message about a 3.5–4.0 game only ever reaches players in that band, so it’s relevant by construction rather than by clever targeting.
4. It closes both ends of the gap. When a session is under-filled, it drafts a recruiting message to the matching group. When a session is full and has a waitlist, it looks for a similar session — same band first, adjacent band as a fallback — with open capacity, and offers those waitlisted players a way in instead of leaving them stuck in a queue.

Does this only work for pickleball?

No — the pattern generalizes to any resource with a booking calendar and a group of people who want to use it efficiently: tennis and racquet clubs, co-working spaces with bookable rooms, gyms with class capacity limits, even recurring meetup groups coordinating around a shared venue. The specific pieces change (the booking platform, the way people are grouped, the capacity math), but the shape of the problem — some slots are under-filled while others have stuck demand — shows up anywhere supply is scheduled in advance and coordination is left to a person watching a spreadsheet or calendar.

What does it take to build one of these?

Three things: read access to whatever calendar or booking system already tracks demand, a lightweight player/member database (schedule, level, contact preference), and an agreed communication channel players already use. From there it’s a matter of defining capacity targets and the fill/rebalance logic for the specific resource being coordinated.