A project is the top organizational unit in many appointment scheduling systems. It combines several calendars, staff, settings and configurations into one logical unit. Projects make it possible to clearly separate different booking areas within one system and configure them differently, whether for different locations, departments, brands or completely separate business units. For operators with just a single calendar, the project concept is usually invisible; for larger organizations, however, it is a central structuring tool.
Typical use cases
1. Multiple locations
A hair salon chain runs 5 salons in different cities. Each location is set up as its own project:
- Project "Downtown" with 3 hairdressers
- Project "Riverside" with 4 hairdressers
- Project "Uptown" with 2 hairdressers
Each project has its own opening hours, its own prices, its own team and its own public booking page.
2. Separate departments
A clinic has different specialist areas:
- Project "General medicine" with its own doctors and office hours
- Project "Physiotherapy" with its own therapists and treatment rooms
- Project "Psychotherapy" with its own psychologists and appointment lengths
Each department has separate booking processes, its own forms and different appointment reasons.
3. Different booking pages
A service provider offers different product lines:
- Project "Individual coaching" for 1:1 consultations
- Project "Group workshops" for seminars with several participants
- Project "Online courses" for virtual meetings
Each project has its own booking page with a different design, other prices and customized texts.
4. White-label applications
An agency runs appointment booking for several clients:
- Project "Client A: massage practice"
- Project "Client B: law firm"
- Project "Client C: photo studio"
Each project is completely isolated; the clients see only their own data.
Properties and configurations at project level
- Own booking page: URL, design, colors, logo, texts
- Own staff/users: Access management, roles, calendar assignment
- Own appointment reasons: Services, durations, prices
- Own email templates: Confirmations, reminders, cancellations
- Own payment integration: Stripe account, PayPal account
- Own privacy settings: Separate GDPR configuration
- Own statistics: Reports for this project only
- Own language and time zone: Internationalization per project
Hierarchical structure
``` System └── Project 1 ├── Calendar 1 (Staff member A) ├── Calendar 2 (Staff member B) └── Calendar 3 (Resource Room 1) └── Project 2 ├── Calendar 1 (Staff member C) └── Calendar 2 (Staff member D) ```
Advantages of the project structure
- Clear separation: Different business units remain organizationally and technically separate
- Individual customization: Each project can be configured completely differently
- Scalability: New locations or areas can easily be added as a new project
- Access control: Staff can be restricted to one or more projects
- Separate booking pages: Different URLs, designs and branding for different target groups
Distinction from other structural elements
- Calendar: A single appointment calendar within a project, usually assigned to a staff member or a resource
- Appointment reason: Type of service that can be booked (e.g. "Haircut", "Initial consultation")
- Resource: Physical objects such as rooms, equipment or vehicles that can be booked
- User: Person with access to the system (administrator, operator, staff member)
Typical setup for small vs. large organizations
Small (1 location, 1 to 3 staff members)
- 1 project
- 1 to 3 calendars (one per staff member)
- All settings bundled in one project
Medium (several locations or departments)
- 3 to 10 projects
- Several calendars per project
- Central administration, but local customizations
Large (franchise, chains, enterprise)
- 50+ projects
- Hundreds of calendars
- Central admin level with delegated rights per project
Technical implementation
Projects are stored in the database as separate entities. All associated data (calendars, bookings, customers, settings) is linked via a project ID. When the booking page is opened, the correct project is loaded automatically. In the admin area, administrators can switch between projects or manage several at the same time.
Best practices
- Meaningful naming: Clear, descriptive project names make administration easier
- Consistent structure: Where possible, all projects should follow a similar logic
- Delegated administration: Project managers should only have access to "their" project
- Regular review: Are all projects still active? Are there orphaned projects that should be archived?
When should you create multiple projects?
- When locations, departments or business units need to be clearly separated
- When different teams work with different permissions
- When different booking pages with their own branding are needed
- When different payment flows (e.g. separate bank accounts per location) have to be mapped
When is one project enough?
- For a single location
- When all staff members work together as one team
- When a single booking page is sufficient
- When all settings and configurations are identical