Bookable resources
Model the actual capacity needed for each booking type.
Booking and scheduling
Let customers book a time that is actually available
OfferAgent SchedulingCore publishes real availability from configured resources, booking types, buffers, lead time, horizon and timezone. A customer temporarily holds an offered slot while completing the booking, and atomic confirmation prevents double booking. The team can then reschedule, cancel or complete the booking with a revision-aware history connected to the customer journey.
Availability must be true when the customer chooses
A list of suggested times is not enough if simultaneous visitors can book the same resource.
How it works
- 01
Configure resources
Define people, teams or other bookable capacity.
- 02
Publish availability
Combine weekly windows, buffers, lead time and horizon.
- 03
Hold and confirm
Temporarily hold a slot and confirm it atomically.
- 04
Manage the outcome
Reschedule, cancel, complete or record a no-show with history.
Product proof: availability to outcome
The scheduling workspace exposes resources, pages, bookings and conflicts as separate states.
Prerequisite: Requires Scheduling access, a resource, booking type and published booking page.
Scheduling workspaceProduct flow
- 1Availability published
- 2Slot confirmed
- 3Outcome recorded
Open the signed-in product workspace
Sign-in and the correct plan are required. This link is not a public demo.
What this capability supports
Timezone-safe slots
Calculate and display availability with explicit timezone handling.
Double-booking protection
Use expiring holds and atomic confirmation for concurrent visitors.
Lifecycle history
Keep reschedule, cancel and completion changes traceable.
Prerequisites and clear boundaries
OfferAgent states what the capability does and what still requires configuration, permission or a human decision.
- External calendar sync is separate from core OfferAgent availability.
- Accepted quotes do not create a booking unless a configured workflow offers that next step.
- Public confirmation requires a unique hold secret, a running expiry process, a published booking page and an available resource.
Frequently asked questions
Do we need Google Calendar?
No. SchedulingCore can publish native availability; provider sync is a separate integration.
How is double booking prevented?
A short hold reserves the slot and confirmation is performed atomically.
Can customers reschedule?
The booking lifecycle supports guarded rescheduling when the account exposes that flow.
Are reminders automatic?
Only when a separate published automation sequence is connected to booking events.