What you enter — and what you can skip.

And what is filled in for you

Every event arrives with sensible defaults, so a new event is usable the moment it has a name. Change them per event whenever the default is wrong.

A project's start and end dates are the one pair of fields people expect to be decorative and are not. They bound the repeat on the calendar feeds attendees subscribe to, so a subscription stops on the right week instead of running forever. Past the end date, new solver runs are refused — everything else still works, you can still view, edit, publish and send links, but a finished term cannot be silently re-scheduled. Push the date out and runs resume.

Thirty days after a project ends, its draft run history is thinned back to the most recent few. Published schedules are never touched.

Availability windows are per weekday: a person is free from this time to that time. Someone with no windows at all is treated as free at any time, which is the sensible default for the majority of attendees who genuinely do not care.

A window can also be starred as preferred. Plain availability is a hard rule the solver will never break. A star is a wish — it feeds a weighted preference, so the solver tries to honour it and gives it up rather than leave someone unplaced. Two different strengths of the same idea, which is what makes the distinction worth having.

Each event decides for itself how much it cares. That is a per-event setting, not a project-wide one, so a project can mix events that need a room with events that do not.

Instructors

None

The default. No instructor is scheduled for this event.

Any eligible

The event needs an instructor and the solver picks one from those allowed to take it and free at that time.

This one

A named instructor, and the event is scheduled around their availability.

Rooms

None

The default. No room is allocated.

Any room

Any room that is free and big enough for the session.

Any eligible room

Restricted to a list — the studios with a piano, the labs with the right kit.

This one

A named room.

Whichever mode you pick, the same two guarantees hold: nothing is ever double-booked, and a room is never given an event larger than its capacity. Rooms have no availability calendar of their own — a room is assumed open whenever the project runs, and it is the events and instructors that carry the time constraints.

Attendee groups

Labels on people — Beginners, Year 9, Saturday crowd. Used for filtering, bulk enrolment and sending an email to just that group. Not a solver constraint.

Event groups

Collections of events that belong together. Beyond tidiness, they fan instructor and room eligibility out across every event in the group at once, which saves setting the same list eight times.

Equivalence groups

The powerful one: a set of interchangeable events where each attendee should end up in exactly one. Enrol someone in the group and let the solver choose which sitting fits their week.

Group assignments

Assign a whole attendee group to a whole event group in one action. It fans out into real enrolments, and can be reversed as a bundle if you got it wrong.

• →Type it. A grid for bulk-adding attendees, and forms for everything else.
• →Import a CSV of attendees — name and email columns, drag the file onto the page.
• →Share the public enrolment link and let people add themselves. No account needed on their side, and it is the fastest way to start.
• →Roll a term over. Copy an existing project to seed the next term rather than rebuilding it.

• →Export everything as JSON — organisation, projects, people, events, enrolments, schedules, users. Your data, on request, in one file.
• →Print or save any schedule as a PDF, with your own logo on the header.
• →Subscribable calendar feeds for every attendee and instructor.

Three roles. Viewers read everything and change nothing — and viewers are unlimited on every plan, so giving the whole team visibility never costs anything. Admins do the day-to-day work: people, events, runs, publishing and branding. Owners additionally handle billing, invite and remove members, and can delete the organisation.

Every consequential action is written to an activity log — projects created and deleted, people invited and their roles changed, schedules published, notifications sent. Plan limits apply to admin seats only.