A calendar that books and bills itself.
Every merchant in your network publishes service and event calendars with their own checkout. The customer books and pays in the same flow where they just chatted with the assistant — no human in the loop, and the booking lands in the network's transactional history.
One booking surface, per merchant.
A customer asks for an opening, picks a slot and is handed straight to checkout — all inside your network. The booking views are live; the online payment step ⚠️ is still in integration, so we show it as a wireframe, not a shipped screen.
Illustrative — real product screenshots coming soon. The payment confirmation is a concept, not a built screen.
Honest about payments
The booking architecture is ready and the per-calendar gateway structure is in place. Online payment rails are still in integration ⚠️ — the same transparency standard we hold on Marketplace. We label every claim Production, Partial or Roadmap so you always know what ships today versus what's coming next.
Booking and payment shouldn't be two systems duct-taped together.
Most service businesses juggle a paper diary, a separate booking app, and a payment link that never talks to either. Calendar collapses all of it into one flow.
Book appointments & events
Schedule slots, classes and events, and coordinate availability across multiple locations — one source of truth instead of a scattered diary.
Charge deposits & services
Take a deposit to kill no-shows, or collect for the full service — each calendar carries its own checkout modality. ⚠️ Payment rails in integration.
Coordinate multi-location availability
Per-merchant calendars live inside the same network, so every shop and professional manages its own schedule without stepping on anyone else's.
From “do you have an opening?” to a confirmed booking — without a human.
The space is the router: the customer who asked the assistant is the customer who books, in one continuous flow that never leaves your network.
- ✓One flow, not three apps — calendar, checkout and assistant in a single conversation, instead of double-entry between a diary and a payment tool.
- ✓Per-merchant calendars — multi-merchant is native, so every local or professional runs their own schedule inside one network.
- ✓Deposits that stop no-shows — the structure to take a deposit per booking is in place; the payment rails are landing next.
- ✓Every booking is a network event — confirmed bookings flow into the network's transactional history, not a silo you can't query.
Attention to action, all in one network.
No channel switching, no handoff, no “I'll call you back to confirm.”
Attention
A schedule that sells on its own — an agenda that turns availability into revenue.
Interest
Each merchant in your network publishes service and event calendars with their own checkout, right where the customer is already chatting.
Desire
From “do you have an opening?” to a confirmed booking with no human intervention — and the event stays in the network's transactional history.
Action
Set up your calendar and let bookings land themselves. ⚠️ Online payment closes the loop once the rails finish integration.
What ships today, and what's still landing.
Status glyphs are exact: a warning means the capability is real in architecture but not yet live end to end.
| Feature | Advantage | Benefit |
|---|---|---|
| Per-merchant calendars ✅ | Multi-merchant by design | Every local or professional runs its own |
| Gateway per calendar (structure) ✅ | Flexible checkout modality | Each service with its own way to charge |
| Online payments — in integration ⚠️ | Status honesty | A prioritized, public roadmap item |
Honest by design
The transactional structure is complete; the payment processor is what's left. We tell you exactly what's missing rather than dressing a Partial capability up as Production.
Better together with the rest of your network.
Calendar is one composable module — it pairs naturally with commerce and the assistant that fields the request in the first place.
Marketplace
Same network, same transactional spine. A product sale and a booked service share one history, one reputation and one checkout story — including the same payment rails now in integration.
Explore Marketplace →
HAI Engine
The assistant that answers “do you have an opening?” is the same engine that hands the customer straight into the calendar — the conversation becomes the booking.
Explore HAI Engine →Turn your availability into confirmed bookings.
The booking architecture is ready today and the payment rails are landing next. Get set up now, and be first when online checkout goes live.