Booking & Pricing Rules Engine

The Problem with Hard-Coded Booking Logic

Every experience hospitality business has booking rules. Surf camps enforce Saturday-to-Saturday check-in because surf lessons are structured in weekly programmes. Retreat centres require minimum 3-night stays because a 2-night retreat doesn't deliver the therapeutic benefit the guest expects. Adventure lodges restrict certain activities to guests over 16 for safety and insurance reasons. Eco-resorts cap occupancy at 80% to maintain the guest experience. These rules are not edge cases — they are fundamental business logic that determines what can be booked, by whom, for how long, and at what price.

In most booking systems, these rules are either hard-coded (requiring developer intervention to change) or absent entirely (enforced manually by staff reviewing each booking). A surf camp using Cloudbeds might set a minimum stay of 7 nights but has no way to restrict check-in to Saturdays only — so they get Wednesday arrivals that disrupt the weekly programme. A retreat centre using Bookingkit might enforce a minimum stay but cannot configure age restrictions on specific activities within a package. The result is staff spending time policing bookings after the fact, sending awkward emails explaining that the booking can't be honoured as submitted, and manually adjusting what the system should have prevented in the first place.

Artidal's Booking & Pricing Rules Engine replaces this patchwork of hard-coded constraints and manual enforcement with a configurable rule system powered by json-rules-engine. Operators define rules through a structured interface — no code required — and those rules are evaluated automatically during the booking flow, preventing invalid bookings before they reach staff.

Rule Categories and Common Patterns

The rules engine supports six categories of booking rules, each addressing a specific operational pattern common in experience hospitality.

Duration rules control minimum and maximum stay lengths. A surf camp sets a 7-night minimum during peak season (to maintain weekly programme integrity) but allows 3-night minimums during shoulder season (to fill beds that would otherwise be empty). A yoga retreat sets a 14-night maximum (to ensure room turnover for other guests during popular periods). Duration rules can vary by room category, season, and package type.

Check-in and check-out day rules restrict which days of the week a stay can begin or end. The Saturday-to-Saturday pattern is the most common — surf camps and retreat centres structure weekly programmes around a fixed arrival day, with orientation on arrival evening and the first session the next morning. But variations exist: some camps allow Sunday arrivals for a 6-night mid-week programme, others permit Wednesday arrivals for a short 4-day taster experience. Artidal supports any combination of allowed check-in and check-out days, with the ability to define different day rules per season and per room category.

Capacity rules define how the system behaves when a room, activity, or property approaches or reaches capacity. Three modes are available: Block (prevent further bookings), Exclude (hide the option from the booking flow but allow manual override by staff), and Allow Overbook (permit bookings beyond capacity up to a configurable buffer — useful for activities where a 10% no-show rate is expected). Capacity rules apply at bed-level for rooms, session-level for activities, and property-level for overall occupancy.

Age, Guest Type, and Eligibility Rules

Experience hospitality activities carry genuine risk profiles that require age and eligibility restrictions. Surfing lessons for beginners might be restricted to ages 10 and above due to ocean safety. Cliff jumping excursions might require a minimum age of 18 and a signed liability waiver. Yoga classes might have no age restriction but require guests to disclose pregnancy for modified instruction. These restrictions aren't optional — they are often mandated by local regulations, insurance policies, or the activity provider's own safety standards.

Artidal's rules engine enforces age and eligibility rules at the point of booking. When a guest configures a package that includes a restricted activity, the system checks the guest profile (or requests the required information during booking) and prevents the restricted component from being added if eligibility criteria are not met. The guest receives a clear explanation: 'The Cliff Jumping Excursion requires all participants to be 18 or older. Your party includes a 15-year-old. You can continue with the remaining activities, or choose an alternative excursion suitable for all ages.'

Guest-type rules extend beyond age to include categories like returning guest (eligible for loyalty pricing), group leader (receives a complimentary upgrade), corporate booking (different cancellation terms), and travel agent (commission-adjusted pricing). These guest types are defined by the operator and can trigger different pricing, availability, and booking flow behaviour through the rules engine.

Prepay and Payment Rules

Payment rules in experience hospitality are more complex than 'pay now' or 'pay at property.' A surf camp might require a 30% deposit at booking for reservations more than 60 days out, a 50% deposit for bookings 30-60 days out, and full payment for bookings less than 30 days before arrival. A retreat centre might require full prepayment for all bookings during a flagship retreat (because they need to confirm catering and guest numbers with the chef) but allow pay-on-arrival for standard stays. Group bookings over 10 guests might require a non-refundable deposit to protect against late cancellations that leave the property half-empty.

Artidal's prepay rules are configurable by season, lead time, booking size, package type, and guest type. The rules engine evaluates the applicable payment requirements during checkout and presents the guest with the correct payment options — deposit amount, instalment schedule (if configured), full payment, and payment deadline. The system integrates with the Financial Management module to enforce payment deadlines: if a second instalment is due 30 days before arrival and the guest hasn't paid, the automated reminder sequence triggers. If the deadline passes without payment, the configurable escalation action fires — which might be a final reminder, a booking hold, or an automatic cancellation with deposit forfeiture.

For operators who have suffered from last-minute cancellation losses — a significant problem in experience hospitality where a 10-bed group cancelling 2 weeks before arrival can represent €8,000-€15,000 in unrecoverable revenue — the ability to configure non-refundable deposit rules with automatic enforcement is transformative. It shifts the cancellation risk from the operator to the guest, which is standard practice in the industry but impossible to enforce without automated payment rule logic.

The json-rules-engine Foundation

Under the hood, Artidal's rules engine is built on json-rules-engine — an open-source, battle-tested rule evaluation library used in production by financial services, logistics, and e-commerce platforms. Each rule is defined as a JSON structure with conditions (the 'if'), events (the 'then'), and priority (the evaluation order). This architecture provides several advantages over hard-coded business logic.

First, rules are data, not code. Operators modify rules through the dashboard, and changes take effect immediately without deployment cycles or developer involvement. A surf camp owner who decides mid-season to reduce the minimum stay from 7 to 5 nights for October bookings can make the change in two minutes — not two weeks waiting for a developer to modify the booking logic, test it, and deploy.

Second, rules compose predictably. When multiple rules apply to a single booking — a duration rule, a check-in day rule, and a prepay rule — they evaluate independently and their effects combine. The system reports which rules passed, which failed, and why, providing transparent feedback to both the guest (during booking) and the operator (in the rules log). This composability eliminates the category of bugs where changing one business rule inadvertently breaks another.

Third, rules are auditable. Every rule evaluation is logged with the booking context, the conditions evaluated, the results, and the actions triggered. When an operator asks 'Why was this booking rejected?' or 'Why did this guest get a different price?', the answer is in the rule evaluation log — not in a developer's head or buried in application code.

Seasonal and Contextual Rule Overrides

Experience hospitality is fundamentally seasonal, and booking rules must adapt accordingly. A surf camp's Saturday-to-Saturday check-in pattern might apply during the peak surf season (May–October) but relax to any-day check-in during the off-season when filling beds takes priority over programme structure. Minimum stay requirements might tighten during Christmas and New Year (7-night minimum to prevent short stays that waste prime-week capacity) and loosen during shoulder months (2-night minimum to attract weekend visitors).

Artidal's rules engine supports date-range overrides on every rule. Operators define the base rule and then create seasonal variants with specific effective dates. The engine evaluates rules based on the guest's travel dates, not the booking date — so a booking made in March for a July stay is evaluated against July's rules, not March's. Multiple seasonal overrides can coexist, with priority resolution for overlapping date ranges.

This contextual rule evaluation extends to special events and one-off situations. When a surf camp hosts a competition weekend and needs to block check-ins on Friday and Saturday, the operator creates a temporary check-in day override for those specific dates without modifying the year-round Saturday check-in rule. When the dates pass, the override expires automatically and the base rule resumes.

Integration with the Booking Flow

The rules engine is not a post-booking validation layer — it is embedded in the booking flow itself. As the guest selects dates, room types, packages, and guest details, the engine evaluates applicable rules in real-time and adjusts the interface accordingly. Dates that violate check-in day rules are greyed out on the calendar. Room categories that are at capacity are marked as sold out (or hidden entirely, depending on the capacity mode). Activities with age restrictions are flagged when the guest's party includes minors. Payment requirements update as the guest changes their dates or package selection.

This real-time, inline rule enforcement is critical for conversion. A guest who completes a multi-step booking flow only to be told on the final page that their selected dates aren't allowed, or that an additional deposit is required, will abandon the booking. By enforcing rules at each step — showing only valid options, explaining restrictions clearly, and adjusting pricing transparently — the booking flow eliminates surprises and builds trust.

For operators, the dashboard provides a rule simulation tool: enter a hypothetical booking scenario (dates, guests, package, room type) and see exactly which rules evaluate, which pass, which fail, and what the guest would experience. This simulation capability is invaluable when configuring complex seasonal rule sets — operators can verify that their intended booking experience works correctly before publishing the rules.