Product case study · Platform architecture
One booking engine for hourly, daily, and variable-duration services
Anolla is built around resources, availability, and rules rather than a template for a single industry. As a result, the same core engine can manage appointments, group services, spaces, and rentals without requiring a separate software product for each service model.
This technical overview explains how Anolla models different scheduling methods through a unified resource and availability logic.
Core scheduling models: hourly, daily, and variable duration.
Configuration scopeResource types supported by the current configuration model.
Verified platform capabilityA unified availability and conflict validation engine.
Architectural principleWhat problem does a unified booking engine solve?
Many scheduling platforms start with a fixed appointment calendar and add exceptions later. Anolla takes the opposite approach: it separately defines what is being booked, how long it is needed, and which conditions must be met. This creates a reusable common foundation for different types of service businesses.
The challenge
An appointment may require one specialist for 45 minutes, a rental service may reserve an item for several days, and a group service may allow multiple participants in the same time slot.
Design decision
Resources, time, and constraints are modeled separately so that availability can be calculated using reusable components.
Platform outcome
One core engine supports different booking scenarios through a unified management model while maintaining a consistent customer experience.
Why is a calendar alone not yet a booking engine?
A simple calendar can show available and occupied times. A production booking system must determine what can be booked, which resources are required, how the duration is defined, whether capacity remains, and whether another booking has changed the situation before confirmation.
These decisions become complex when the platform serves more than one business model. Building a separate calendar for each category would duplicate logic, fragment the user experience, and make future changes more difficult to manage.
Appointments
Require a specialist, a service duration, and buffer times between customers.
Group services
Require capacity management rather than exclusive use of a time slot.
Rooms and courts
May be bookable in fixed intervals and depend on opening hours and access rules.
Rental items
May use day-based periods, handover windows, and multi-day availability.
The service category should describe the business context, not define the limits of the scheduling engine.
Which principles make it possible to use one engine for different service models?
Anolla's booking model consists of independent layers. Each layer addresses one type of question and can be reused when adding a new domain or booking scenario.
01 · Resource-centric structure
Anything that limits availability can be treated as a resource: a specialist, room, court, piece of equipment, table, vehicle, service point, or any other bookable item.
02 · Domain-independent scheduling model
A service can use an hourly time slot, a day-based period, or a variable duration without requiring a separate product architecture for each category.
03 · Centralized constraint evaluation
Schedules, capacity, buffer times, booking windows, and overlapping bookings are evaluated together before a time is offered and again before confirmation.
04 · One model across customer and administrative flows
The public booking page and administrative tools use the same availability logic, reducing the risk of inconsistent options.
How does the configuration flow into the availability engine?
The engine does not start with the name of the business domain, but with the resources, scheduling model, and constraints required for the booking being evaluated. The same decision logic is used for both public bookings and bookings created through the admin interface.
Configuration inputs
Availability engine
Calculate · compare · validate
A unified engine combines the configuration, checks availability, and applies booking rules before returning the result.
Engine outputs
The conceptual diagram describes the availability decision flow, not the complete technical architecture of Anolla's internal systems.
How does the same engine handle different service scenarios?
The configuration varies by scenario, but the core engine always answers the same questions: which resources are required, for how long, under which constraints, and how much booking capacity remains?
| Scenario | Scheduling model | What the engine evaluates | Reusable platform logic |
|---|---|---|---|
| Specialist appointment | Variable duration | Service duration, the specialist's schedule, preparation or cleanup time, and existing bookings. | Resource availability, duration calculation, advance notice, and conflict checking. |
| Group class | Fixed duration | Class schedule, instructor, room, participant limit, and number of available spots. | Multiple-resource validation, capacity tracking, booking windows, and confirmation rules. |
| Court or room | Hourly | Opening hours, booking interval, resource occupancy, preparation time, and optional add-ons. | Generating bookable time slots, excluding overlapping bookings, and displaying availability. |
| Rental property | Daily | Start and end dates, handover windows, property availability, and overlapping rental periods. | Period validation, resource status, booking rules, and final availability check. |
How does the same engine support combinations of multiple services?
A single booking does not always have to mean a single service. A customer may want several related services in sequence, and the service provider can specify which services can be booked independently and which only together with another service.
The booking engine treats the selected services as a single unit: their durations, breaks, prices, and required resources form a combination used to find suitable times and create one booking.
One booking, multiple services
The customer can select multiple compatible services within a single booking without creating separate bookings.
Configurable combinations
The service provider can specify which services can be booked independently and which form a combination.
Unified availability calculation
Availability is calculated based on the total duration of the combination, breaks, and required resources.
Combining services does not require a separate booking engine. The same resource, duration, and availability logic can assess the suitability of both a single service and a booking consisting of multiple services.
How does configuration lead to a confirmed booking?
The booking flow follows a consistent sequence even when the service visible to the user and the scheduling model differ.
Define what can be booked
The service provider specifies the primary resource and all additional resources required to deliver the service.
Choose the scheduling model
The service uses an hourly time slot, a daily period, or a duration determined by the service and additional options.
Apply schedules and constraints
Working hours, capacity, buffer times, notice periods, booking windows, and other rules limit theoretical availability.
Find options to display to the customer
The engine returns only the times or periods that match the configuration active at the time of the request.
Recheck availability before confirmation
A new check protects against conflicting changes made during the selection process.
What capabilities result from a shared booking engine?
The outcome is not that all businesses use an identical configuration. Different configurations can rely on the same tested decision engine and shared governance principles.
Unified management model
Users manage resources, services, schedules, and rules through shared concepts.
Reusable validation rules
Conflict checks and constraints are managed centrally, allowing multiple service models to benefit from improvements.
Consistent customer journey
Appointments, rooms, and rental services can follow a familiar booking pattern even when their availability rules differ.
Extensible platform foundation
New resource categories and service combinations can be added by extending the configuration and rules.
What exactly do the claims in this case study mean?
This is a product case study, not a client story. It describes Anolla’s current booking model, supported resource configurations, and functional decision flow. Scope metrics describe the platform’s capabilities and are not outcomes promised to any specific business.
Capability foundation
The platform’s current configuration, supported resource type system, and existing scheduling models.
Functional evidence
Booking scenarios evaluated through the same availability and conflict checks.
Data usage
The case study does not use data from identifiable clients or the individual performance metrics of any business.
Interpretation
The page demonstrates the platform’s scope and the reusability of its architecture, not guaranteed client outcomes.
Limitations. A flexible core does not make workflows identical across all industries. Industry-specific requirements, custom integrations, physical access systems, or unusual pricing rules may require additional configuration or development. The accuracy of availability depends on the quality of the schedules, resources, and rules entered by the service provider.