Will it actually work with the system that holds our timetable?

Reading the timetable and writing to it are different projects

Reading is usually straightforward: the assistant can tell a member what is on and when. Writing - actually placing someone in a class, moving them off a waitlist, cancelling within the window - needs credentials, an API that permits it, and agreement about what happens when two bookings race. Many vendors call the first one "integration". Ask which direction they mean.

What works with no integration at all, and it is not nothing

Published rules: the waitlist order, the cancellation window and why it is that long, membership terms, what a trial includes, whether an induction is required, the no-show policy. Those answers resolve most evening messages and need no connection to anything. A club that starts here finds out how much of the load was never about booking.

The failure mode to design against

An assistant that reads a stale copy of the timetable will tell a member a class is on when it was cancelled this morning, and will do it with complete confidence. That is worse than not answering, because the member drives in. If the connection is read-only or cached, the assistant must say what it cannot confirm - and a club should test that sentence before going live, not read it in a brochure.

Three things to check before signing

Which named systems have been connected before, not which are theoretically possible. Whether the connection reads, writes, or both. Who does the integration work and whether it is inside the price. A vendor who answers all three with specifics is describing a project; one who answers "we integrate with everything" is describing a hope.