Inventory Model
- Bookable Unit Type
- Capacity Model
- Availability Source
A credible booking MVP joins real availability rules to slot selection, confirmation, payment, reminders, provider operations, rescheduling, cancellation, and support. Calendar concurrency and timezone behavior are core requirements, not polish.
For teams whose product lives or dies by scheduling reliability. A booking platform is not just a calendar view. It is a structured promise about time, capacity, provider coordination, and what happens when plans change.
Supported Decisions
These decision areas and option sets come from the application-type specs used by the workspace.
Planning Signals
These notices are generated from the same priority and mapping files used by the workspace.
Confirmation model determines booking state, notifications, and capacity handling.
Pricing basis changes availability rules, quote calculation, cancellation policy, and booking confirmation expectations.
External calendar sync should align with the core external-sync model.
Approval-gated bookings usually need explicit admin approval work-item handling.
Waitlist backfill should align with the core advanced scheduling capability.
MVP planning snapshot
A credible booking MVP joins real availability rules to slot selection, confirmation, payment, reminders, provider operations, rescheduling, cancellation, and support. Calendar concurrency and timezone behavior are core requirements, not polish.
The reviewed appointment example covers customer, provider, and admin roles, availability, booking changes, payments, reminders, schedule operations, and support. Its reproducible calculator assumptions produce about 111-380 adjusted person-days, EUR 72,000-EUR 247,000, and 11-33 weeks.
These figures are planning ranges, not quotations. Change scope, rate, delivery coverage, capacity, and risk choices in the calculator.
Reviewed 10 August 2026.
Booking platforms differ dramatically depending on whether the bookable unit is a time slot, room, provider, asset, or mixed resource combination. Capacity can be single-occupancy, pooled, or dependent on several constraints at once. The product scope should make the inventory model explicit because it determines how customers search, how operators schedule, and where errors are most likely to happen.
Some booking journeys start with date. Others start with provider, location, or a guided finder that narrows the right option before time is chosen. The correct entry point depends on the category. A haircut, a hotel room, a medical visit, and an equipment rental all create different decision sequences. The product scope should show that the product understands this rather than assuming a generic booking funnel.
A booking platform can serve one provider, a roster of providers, multiple locations, or a distributed network. Each model changes how assignments, conflicts, buffers, and schedule updates must be handled. That is why provider coordination belongs in the application-type story. It is not back-office logic. It is the engine that determines whether customers experience the booking as dependable.
No booking system is evaluated only on the happy path. Reschedule requests, self-service changes, policy-aware cancellation, waitlists, reminder timing, and preparation instructions all shape whether the product feels mature. If every change requires manual intervention, the schedule becomes expensive to maintain and frustrating to use.
Decision Criteria
Use these questions to decide which supported options deserve attention before a project is scoped.
Call To Action
If availability, confirmation, coordination, and post-booking operations are aligned, the schedule feels trustworthy. If they are vague, the business pays for confusion in no-shows, support effort, and lost utilization.