Modules · Schedule.software
Seven modules on one calendar substrate — and a straight answer on which are finished.
Most scheduling companies own one column of this board. A calendar tool does appointment links and stops. A field-service platform does dispatch and has no consumer booking page. The modules below are the same availability engine packaged for seven different kinds of operation, which is why a double-book between an appointment link and a crew dispatch day is structurally impossible rather than a setting somebody remembered to turn on.
Of the seven, 2 are built and running, 4 have a built engine with a surface still in development, and 1 is planned and not built. That breakdown is on every row of the table and beside every heading below, because a status that only appears in one place is a status somebody will read past.
The seven modules — scroll sideways on a narrow screen
What each module is for, and exactly how far along it is
| Module | Packaged for | Build status |
|---|---|---|
| Appointment links | Solo professionals and small teams | Engine built · public booking page in development |
| Business-services booking | Appointment-based businesses | Engine built · self-serve surface in development |
| Room & resource management | Facilities, campuses, venues | Built · production-ready in the Education edition |
| Field-service dispatch & routing | Field service and mobile crews | Built · production-ready · consumer booking page in development |
| Workforce shift scheduling | Shift-based operations | Claim flow built · full WFM layer in development |
| Events & reservations | Events, classes and reservations | Events package built · self-serve creation in development |
| Personal & family scheduling | Households and families | Planned · minor-safe architecture designed in from the start |
“Partial” on this table means something specific and slightly unusual: the engine is built and running — it is the same engine the production K-12 surfaces use — and the self-serve surface a customer would touch is still in development. It does not mean a prototype. “Planned” means designed and not built, and it appears exactly once on this page.
Module by module
The seven, in full
Personal scheduling that knows the rest of your calendar
Appointment links · Engine built · public booking page in development
An appointment link is not a separate product here — it is the same availability engine that drives room booking and crew dispatch, surfaced as a personal link. A solo professional or a team member publishes their open hours; a client picks a time; the booking lands. The availability engine already knows rooms, crews, and shifts, so a double-book between an appointment link and a crew dispatch day is structurally impossible — not a setting to configure, a property of the model. Custom domain and branding are not paywalled to the top tier.
Multi-staff, multi-resource booking without the vertical lock-in
Business-services booking · Engine built · self-serve surface in development
For appointment-based businesses that need more than a personal link: multiple staff, multiple service types, and resource overlap detection that is a baseline feature, not a premium add-on. A service-based business books a staff member, a treatment room, and the required equipment in one booking event; the engine enforces exclusivity for all three simultaneously. No vertical lock-in — the same engine serves a fitness studio, a clinic, a salon, or a school photography team. No commission skim on any transaction.
Rooms, equipment, vehicles, and people in one shared availability model
Room & resource management · Built · production-ready in the Education edition
The hard-constraint gate enforces per-space quotas, setup and teardown buffers, approval workflows, and blackout windows natively — these are not bolt-ons or configuration tables. A room and a person can be booked together in one atomic transaction; exclusivity is guaranteed for both at the database. A malformed overlap attempt — two bookings whose windows intersect by even one second — is rejected at the server before any write, using the canonical half-open [start, end) predicate. The facilities booking surface in the K-12 edition runs this engine in production today.
The crown jewel: consumer booking + automatic crew dispatch + route optimization
Field-service dispatch & routing · Built · production-ready · consumer booking page in development
A customer picks a service window on a public booking page; a technician is dispatched with an optimized route, atomically, from the same booking event. No field-service platform on the market does both in one product — the dispatch platforms are operator-only, the booking tools have no dispatch. The dispatch engine covers full job lifecycle (season → job → job day → assignment), credential-gated crew assignment (expiry, territory, role, kit exclusivity), a working in-process route optimizer (VRPTW heuristic default, with OR-Tools and external solver seams injectable), a self-healing reschedule proposer, and an open-shift claim flow with an atomic single-winner check. This engine is built and runs in production on K-12 picture-day operations today.
Shifts that share the same availability and eligibility engine as everything else
Workforce shift scheduling · Claim flow built · full WFM layer in development
Workforce shift scheduling built on the same availability and eligibility gate as appointments, dispatch, and resource booking — so a shift conflict with a booked appointment is caught before any write, not discovered after. The shift open-claim flow (a crew member claims an open shift; a single-winner atomic check confirms the claim) already runs in production. The full workforce management layer — recurring shift templates, rotations, time-off requests, swap and trade, clock-in, and demand auto-fill — is in active development, building on the shared availability and eligibility gate already in place.
Event registrations and reservations on the same slot and capacity engine
Events & reservations · Events package built · self-serve creation in development
Public and private events with slot-based registration, capacity limits, a waitlist, and the same no-double-book guarantee at the database. An event registration is structurally the same as a booking — a slot, a capacity, an attendee — so every invariant the booking engine carries (partial-unique index, transactional capacity count, consent chokepoint) applies to event registrations without a separate implementation. The events package runs in production today; a self-serve event-creation surface is in development.
A personal calendar that is minor-safe by construction
Personal & family scheduling · Planned · minor-safe architecture designed in from the start
The free-tier wedge: a personal and family scheduling surface built on the same engine, with consent-gated calendar sharing as a native feature — not a privacy setting someone configures, but a structural property of the model. A minor’s schedule shared via the subscribable .ics feed contains opaque labels only: no name in the SUMMARY or ORGANIZER fields. A family member sees only their own children’s calendars, gated by the hash-verified family claim. Minor-safe by construction is a property that cannot be retrofitted onto a general calendar; it was designed in from the start.
Modules and surfaces are two different questions
What is packaged, and what is running
The seven modules above are the taxonomy — how the engine is organised for each kind of operation. They are not the same question as what is running in production today. For that, the surfaces page lists the eight K-12 and studio implementations that exist, six in production and two module-dark, each with what it holds and who is entitled to book on it.
Pricing figures for the planned tiers are on the home page, and they are display-only: no card, no charge, no contract signed on a web page. If a module you need is on the partial or planned list and the timing matters to you, say so — that is genuinely how the order gets decided.