Platform architecture
Each company operates independently while the platform admin can oversee tenants, users, settings, and company performance from one product.
Tenant boundary
The platform links operational records to a company so a booking company can only work with its own users, providers, customers, services, bookings, availability, payments, and settings.
Brand, slug, plan, status, website, and account details.
Admins, providers, staff, and customers attached to one tenant.
Appointments, availability, services, and payments scoped per company.
Booking rules, widget text, notices, and confirmation content.
Access model
Creates companies, manages tenant users, and reviews company-level settings.
Runs the company dashboard, services, calendar, team, payments, and integration settings.
Manages their own appointment calendar, statuses, notes, and custom calendar blocks.
Books online and views their own appointment history inside the correct tenant.
Integration
Companies can keep their existing websites while adding a tenant-specific booking entry point that routes customers into the right company context.
<script src="/booking/launcher.js" data-company="company-slug" async></script>Scale path
The data model is structured for SaaS growth: add more companies, add teams inside each company, and preserve separation across every booking workflow.
Talk through rollout