--- title: LaMarie Beauty — Bookly Product Variations Implementation type: article created: '2025-10-14' updated: '2025-10-14' source_docs: - raw/2025-10-14-la-marie-beauty-project-call-94056276.md tags: - woocommerce - bookly - product-variations - booking-ux - client/la-marie-beauty layer: 2 client_source: null industry_context: null transferable: true --- # LaMarie Beauty — Bookly Product Variations Implementation ## Overview During the October 2025 integration progress call, the team identified a key technical constraint: the Bookly widget can filter and display a selected service when a customer clicks "Book Now," but it **cannot natively handle product variations**. Addressing variations requires a custom implementation approach, and the chosen path has significant implications for project timeline. This article documents the options discussed, the approach agreed upon, and the complexity considerations that apply to similar WooCommerce + Bookly setups. --- ## The Core Constraint Bookly's widget supports filtering to a specific service (product), but it has no built-in mechanism for surfacing **variations within a service** (e.g., different durations, formulations, or pricing tiers of the same treatment). When a service has variations, Bookly treats them as a flat list rather than a structured selector. > *"We can't through Bookly go granular and do variations. So if we do variations, it'll have to be individual service pages that we create."* > — Chris Østergaard, developer lead --- ## Implementation Options ### Option A: Individual Service Pages per Variation Create a dedicated WooCommerce page for each variation. Each page passes its own filter parameter to the Bookly widget, pre-selecting the correct service. **Pros:** - Clean URL structure; each variation is independently bookable - Consistent with how Bookly's filter already works for top-level services - Easier to maintain per-page SEO and content **Cons:** - High volume of pages to create and maintain (La Marie has many services with multiple variations) - Hard-coded variable updates required for each product — time-consuming at scale - Any service catalog change requires page-level updates ### Option B: Custom Variation Selector Build a custom UI element (e.g., a tab strip or dropdown) on a single product page. Selecting a variation dynamically sets the Bookly widget's service parameter without a page reload. **Pros:** - Single page per service; cleaner information architecture - Better UX — customers stay in context while choosing a variation - Scales better as the catalog grows **Cons:** - Requires custom development work beyond Bookly's standard configuration - More complex to build and test - Dependency on developer availability --- ## Agreed Approach: New Product Page Layouts with Tabs The team aligned on a **hybrid of Option B**: building new product page layouts that include tabbed or rotating variation selectors. Each tab would correspond to a variation and trigger the appropriate Bookly service filter. > *"When they land on just a product page, then yeah, they've got the different things that rotate through."* > — Melissa Cusumano Key dependency: **new page layouts must be completed before Bookly can be launched.** The client (Roxana) confirmed this explicitly: > *"I don't think we can launch Bookly without the page layouts, because of the way the variations work."* Melissa committed to scheduling a call with the development team to scope and timeline the layout work, with an update expected within the week. --- ## Hard-Coded Implementation Notes The developer had already implemented a hard-coded approach to pass product filter variables to the Bookly widget. While functional for top-level services, scaling this to variations introduces compounding complexity: - Each variation requires its own variable update - With a large service catalog, this becomes a significant manual effort - Any future catalog changes (new services, renamed variations) require corresponding code updates This reinforces the preference for the custom selector approach — it centralizes the logic rather than distributing it across dozens of hard-coded pages. --- ## Timeline Implications The variation handling issue is one of two blockers (alongside the [[wiki/knowledge/zapier/square-zapier-appointment-sync-debugging|Zapier–Square appointment sync]]) preventing Bookly from going live. The end-of-October target was acknowledged as tight, and the team agreed that quality implementation takes priority over hitting the deadline. > *"I'd rather have this done properly rather than roll it out with some potential hiccups."* > — Chris Østergaard As a stopgap, the team agreed to redirect the site-wide "Book Now" button to the full Square booking page, giving clients uninterrupted access to all services while the Bookly integration is completed. See [[wiki/clients/la-marie-beauty/projects/bookly-square-integration|Bookly–Square Integration Project]] for full context. --- ## Generalizable Lessons 1. **Bookly's service filter works at the product level, not the variation level.** Any project using Bookly with WooCommerce variable products will hit this ceiling. Plan for custom development time upfront. 2. **Hard-coded filter variables don't scale.** For catalogs with more than ~10–15 services, a dynamic selector approach is worth the additional build time. 3. **Page layout dependencies can gate integration launches.** Identify UI/UX prerequisites early — in this case, the page layout work was a hidden dependency that wasn't scoped until mid-integration. 4. **Temporary redirects are a valid stopgap.** When a booking flow is broken or incomplete, redirecting to the provider's native booking page (Square, Acuity, etc.) preserves conversion while the custom integration is finished. --- ## Related - [[wiki/clients/la-marie-beauty/projects/bookly-square-integration|Bookly–Square Integration Project]] - [[wiki/knowledge/zapier/square-zapier-appointment-sync-debugging|Square–Zapier Appointment Sync Debugging]] - [[wiki/clients/la-marie-beauty/_index|La Marie Beauty Client Overview]]