A salon or spa runs on two clocks at once. The first is the chair: a colour service that blocks a senior stylist for 140 minutes with a 30-minute processing gap in the middle, a therapist certified for hot stone but not for microdermabrasion, a treatment room that holds one bed. The second is the till: retail shampoo sold at the desk, a prepaid 10-session package drawn down one visit at a time, a gift voucher issued in December and redeemed in March, and a payroll run where every stylist is owed a different percentage on service versus retail. Dynamics 365 Business Central is genuinely strong at the second clock — items, sales, inventory, VAT, receivables — and has essentially nothing for the first. There is no resource-and-room calendar with skill matching, no service menu with duration and processing gaps, no commission engine that splits service and retail at different rates, and no deferred-revenue treatment for a package the customer has paid for but not yet consumed. Salons end up running a separate booking SaaS and re-keying the day's takings, which means Business Central knows the money but never the margin per stylist, per chair, per hour.

We close that gap inside Business Central rather than beside it. The extension is delivered as an AL app — a per-tenant extension for your SaaS environment, or an AppSource-format app package if you prefer that packaging. Staff are modelled on Resource with a new Staff Skill matrix and working-calendar assignment, so a colour service can only be booked against a resource holding the matching skill code and an available room. Services extend Item and Resource with duration, buffer, processing-gap and room-requirement fields; packages are composed as service lines with a drawdown balance held in a new Membership Ledger Entry table that follows Business Central's own ledger-entry conventions — posted, non-editable, reversible only through a correcting entry. Booking, drawdown and commission calculation live in codeunits, and posting is wired to the standard routines through event subscribers on Codeunit 80 Sales-Post and Codeunit 12 Gen. Jnl.-Post Line, so a salon sale is a real posted sales invoice with the right G/L, VAT and dimension postings — not a parallel set of books.

Commission rules are table-driven — rate by staff, service group, retail item category, revenue band or date-effective promotion — and a Job Queue Entry accrues commission nightly into a Commission Ledger Entry table ready for your payroll export. Front desk staff work on purpose-built list and card pages plus a day/week calendar page. The retail lane integrates with your existing POS through API pages on REST API v2.0, and OData v4 endpoints expose availability, bookings and voucher balances to an online booking site or a Power Apps canvas app over Dataverse. Everything ships with its own permission sets, so a receptionist can book and take payment without seeing the G/L, and telemetry is emitted to Application Insights so slow availability searches are diagnosable on a busy Saturday.

Because it is built for your business rather than bought off a shelf, the shape follows your operation. A single-site salon with six chairs gets a lean build: calendar, service menu, commission, vouchers. A ten-location spa group gets location-aware availability, per-site commission schemes, inter-site voucher redemption settled between location dimensions, and membership tiers that carry discount rates into the sales line. Where you already run a booking front end, you keep it and we integrate through the API layer instead of replacing it.

Delivery is build-to-order, and we are direct about what that means. Nothing is downloadable today. We start with a scoping call, agree the service catalogue, commission rules, membership mechanics and POS integration in writing, and quote against that scope. Typical delivery is one working week from confirmed scope, depending on how many commission variants and integrations are in play. We build against your Business Central release wave — SaaS online or on-premises — install into a sandbox first, run user acceptance testing with your front-desk and finance staff on real service and price data, then promote to production in an agreed window with a documented rollback. You receive the AL source, the git repository, and a support window after go-live. If your requirement turns out to be a poor fit for a build — for instance you need a consumer booking marketplace rather than an ERP-side scheduler — we will say so at the scoping call rather than sell you a project.