Internal tooling · Built from scratch
Giving an AI assistant real access to the scheduling system
Every scheduling question took five clicks in a system built for entering data, not answering questions.
Five clicks for one answer
Every routine question — who's scheduled, what we've played recently, which slots are still open, what changed since last week — took five to ten clicks in a system built for data entry rather than for asking questions. Across a weekly planning cycle at multiple sites, that adds up.
Connecting the assistant to the real data
Rather than exporting data and analyzing it elsewhere, I connected the assistant directly to the system of record.
- Built an integration against the platform's API, exposing planning, scheduling and reporting as actions an AI assistant can call.
- Included write access, not just reads, so the assistant can make the change instead of telling me where to click.
- Extended the same integration into a small iOS app for the parts I need on a phone, on a Sunday morning.
Outcome
Planning moved from clicking through screens to describing what I want. The same integration now supports the scheduling analysis I used to do by hand in spreadsheets.
This project convinced me that most "we need a new tool" problems are really "our current tool has no good way to answer the question we keep asking" problems. An API and a small set of well-chosen actions is usually cheaper.
I'm careful about giving an assistant write access. The actions are scoped narrowly and I kept the destructive ones manual. Deciding what not to automate is most of the design work.