Med Spa Software: Memberships, Injectables and Consults That Actually Reconcile

Why med spa software makes or breaks a multi-location operator

A med spa is three businesses stapled together, and most software only understands one of them. You run a retail membership business (recurring monthly billing, banked credits, rollover rules), a controlled-inventory clinic (Botox and Dysport vials with lot numbers, Juvederm and Restylane syringes with expiry dates, thousands of dollars sitting in a fridge), and a provider scheduling operation where a nurse injector, a laser tech and an esthetician have completely different licensure, room requirements and revenue per hour. Zenoti, Boulevard, Aesthetic Record, Mangomint and PatientNow each nail one or two of those and leave you to spreadsheet the rest.

The tell is always the same. Walk into the back office of a four-location med spa on the last day of the month and you will find the practice manager with three browser tabs and one Google Sheet named something like MEMBERSHIP_TRUE_UP_FINAL_v4. Tab one is the booking system. Tab two is Stripe or the merchant portal, because the membership billing engine and the point of sale disagree about who actually got charged. Tab three is the inventory count someone did on a clipboard and typed in later. The sheet exists because no system in the stack can answer the question the owner keeps asking: this member has $1,340 in banked credit, she wants to use it across two locations on a service that was priced differently when she joined, what do we charge her today and which location books the revenue?

In the med spa groups we have worked with, that reconciliation eats 10 to 15 hours a month of a practice manager's time at four locations. The bigger leak is quieter. Injectables shrinkage runs on units, not vials: a 100-unit Botox vial charted as 24 units for one patient and 30 for another leaves 46 units that either got used, got wasted, or got comped, and off-the-shelf inventory that decrements one unit of "Botox" per appointment cannot tell you which. Run your own numbers on that: a vial at roughly $600, thirty vials a month across locations, and even a single-digit percentage of unexplained variance is real money leaving in a sharps container.

Problem: memberships are a financial product and your booking tool treats them as a coupon

Here is the scenario that breaks every off-the-shelf system. A member on your $199/month tier has 11 months of banked credit, $2,189. She joined in a year when your HydraFacial was $185; it is now $225. She wants to redeem at your Scottsdale location but signed up at Chandler. She also wants to gift $400 of it to her daughter. Your front desk person, who has been there five weeks, has to decide.

Zenoti and Boulevard model memberships as a discount attached to a client record, plus a recurring charge. That is the wrong data model for what banked credit actually is. Banked credit is a liability on your balance sheet, and it needs the properties of a ledger: an immutable entry per accrual, per redemption, per transfer, per expiry, each with a location, a service price snapshot at the time of accrual, and a reason code. When the model is a coupon, you get drift, and drift is why the true-up sheet exists.

What a custom build does: a double-entry credit ledger as the system of record. Every membership charge posts a credit entry with the price book version attached. Every redemption posts a debit against specific accruals, oldest first, and the redemption records both the accrual-time value and the today value so the margin delta is visible per transaction rather than discovered at year end. Cross-location redemption becomes an intercompany transfer entry, so Scottsdale's profit and loss statement gets the service revenue and Chandler's carries the liability relief. Gifting is a transfer between member accounts with its own entry type. The front desk person stops deciding anything: the screen shows redeemable balance, the exact price honored, and the one-tap action. Your accountant gets a deferred revenue report that ties out without a human.

Problem: injectables inventory is tracked in units but purchased in vials, and nothing bridges it

Your nurse injector opens a 100-unit vial of Botox at 9:15am. Patient one gets 24 units in the glabella. Patient two at 10:00 gets 30 in the forehead and crow's feet. Patient three at 11:15 gets 20. That vial has 26 units left and a reconstitution clock, because once diluted you have a usable window. At 2pm the injector opens a fresh vial for a patient who could have been served from the open one.

Aesthetic Record and PatientNow will decrement inventory when you chart the treatment. What they will not do is model the open vial as its own object with a lot number, an open timestamp, a remaining unit count and a discard deadline. So you cannot answer: how many units did we waste last month, by injector, by location, by day of week. You cannot answer whether Tuesday's schedule density is costing you a vial a week. And when a manufacturer issues a lot-specific notice, you cannot produce the patient list in under an hour, because the chart says "Botox 24u" and not "lot C4821X, vial opened 9:15am."

What a custom build does: inventory rows are vial instances, not SKUs. Receiving scans the lot and expiry into a vial record. Opening a vial creates an open-vial object tied to a room and a provider shift with a countdown. Charting draws from a specific open vial, and the chart entry stores the lot. Remaining units at close of shift get an explicit disposition: carried, wasted, comped. That single required field, waste reason, is the whole ROI. Once you have vial-level data, the scheduling engine can do the useful thing: when a nurse has an open Botox vial with 26 units and 40 minutes of gap, the system surfaces which waitlisted patients have a treatment plan in that range and offers a same-day text. That turns waste into revenue on a Tuesday afternoon. Lot recall becomes a query that returns a patient list in seconds with a consent-compliant notification draft.

Problem: consults convert on follow-up, and your system's follow-up is a task nobody does

A $4,800 treatment plan for a full-face rejuvenation rarely closes in the consult. It closes on the third touch, 11 days later, when the patient has thought about it and someone answers the question she did not ask in the room: what does the downtime actually look like, and can I do it before my daughter's wedding in March. Your consult notes have that wedding date. Your CRM (Customer Relationship Management) does not, because the note is a free-text blob in a chart.

Boulevard and Zenoti give you campaign blasts and a task list. Neither reads the consult. So the follow-up your coordinator sends is generic, and the plan sits in proposed until it dies. Do the math on your own book: 60 consults a month at a $4,800 average plan is roughly $3.5M of proposed work a year, which means every single point of close rate is around $35,000. You do not need to move it many points to cover a build.

Where AI genuinely helps, concretely: run the consult recording or the injector's dictated note through extraction and populate structured fields, treatment areas discussed, products proposed with units, quoted price, patient-stated hesitation, patient-stated event date, budget signal. Those become real columns, not prose. The follow-up sequence then branches on actual data: an event-date patient gets a timeline-anchored message counting back from March with the pre-treatment schedule; a price-hesitation patient gets the payment plan; a downtime-hesitation patient gets the specific recovery photos for her proposed areas. A human coordinator approves each send in a queue, thirty seconds per patient instead of ten minutes of chart archaeology. The second place AI earns its cost is after-hours booking: a voice and SMS agent that reads real availability by provider licensure, knows a laser consult needs a different room than a filler appointment, and books it, instead of taking a message that gets returned at 11am the next day when she has already booked with the med spa two miles away.

Problem: provider licensure and room constraints are business rules, not preferences

A nurse practitioner can inject. An RN can inject under the supervising physician's protocol, and in some states the supervising physician's presence rules differ by procedure. An esthetician cannot touch a needle. Your laser needs a dedicated room with the door interlock. Your medical director covers three locations and has to be reachable per your state's delegation rules.

Every off-the-shelf booking system models this as provider skills plus resource tags, which is a soft suggestion. A front desk person can override it, and does, at 4:50pm when a patient walks in. Then you have an appointment on the books that your compliance posture says should not exist, and you find out during an audit or, worse, after an adverse event.

What a custom build does: encodes licensure and supervision as hard constraints in the scheduling engine, versioned by state and effective date, with the medical director's coverage as a resource that must be satisfiable for the appointment slot to exist at all. Overrides are possible but they require a named approver and write an audit entry. Good faith exam requirements get modeled as a prerequisite with a validity window, so a patient whose exam expired cannot be booked for the treatment; the system books the exam instead. Room and device constraints, including device maintenance windows and consumable tip counts, sit in the same solver. The result is a schedule that is correct by construction rather than correct by whoever is at the desk.

Problem: multi-location rollups are a monthly export instead of a live number

You have four locations and you are looking at a fifth. The question that decides it is: what is revenue per injector hour by location, net of product cost, with membership revenue recognized correctly rather than counted when charged. Your current answer is a spreadsheet your practice manager builds on the third of the month from four exports.

Zenoti has multi-location reporting; it is real, and it is also generic. It does not know that a membership charge is deferred revenue until redeemed, that an open-vial waste event belongs to a provider shift, or that a consult-to-plan conversion should be attributed to the coordinator and not the injector. The reports are correct about the things the vendor decided to be correct about.

What a custom build does: one warehouse fed by the same event stream that runs the app, so the dashboard is the ledger and not an export of it. Revenue per injector hour computes live, net of the actual units drawn from actual vials. Membership liability shows current, aged, and forecast. Cohort retention by membership tier and join location is a first-class view. When you evaluate location five, the model runs on your real ramp curve from locations two through four rather than a guess. This is also the moment forecasting earns its place: with 18 months of your own booking and redemption data, demand forecasting by service and provider is genuinely predictive, and it drives injector staffing and vial ordering instead of the practice manager's instinct.

What this costs and how long it takes

Across 2,000-plus projects, our delivery experience for this category lands in two bands. A focused first release, the membership credit ledger, vial-level injectables inventory with waste capture, a constraint-aware scheduling engine, and one payments integration, typically runs $60k to $130k and ships in 12 to 16 weeks. A full platform, adding the consult-to-plan pipeline with AI extraction, after-hours booking agent, patient portal, multi-location warehouse and reporting, and migration off the incumbent, typically runs $150k to $400k phased over 6 to 12 months.

What drives price up specifically in med spa work: charting and consent capture, because photo management at treatment-area resolution with before-and-after series is more engineering than people expect, and because the storage and access rules for those photos are not casual. Payments plus membership dunning, because failed recurring charges need a retry ladder and a grace policy or your churn number is a lie. State-by-state licensure and supervision rules, because each additional state is real modeling work rather than a config toggle. Migration, because pulling membership balances and treatment history out of Zenoti or PatientNow means reconstructing the credit ledger from transaction history that was never designed to be a ledger, and that is typically 3 to 5 weeks on its own. Integrations with your existing device software, Cherry or PatientFi financing, and your accounting system each add scope. What holds price down: one state, one payments processor, and an owner who will make decisions in a weekly call instead of a committee.

Build versus buy: the honest line

Buy, genuinely, if you run one or two locations, memberships are a modest slice of revenue, and your injector count is small enough that the practice manager can hold the state of the business in her head. Boulevard at its published tiers plus a good bookkeeper will beat a custom build on total cost for years. Buy also if you are still figuring out your service mix. Building a scheduling constraint engine around a menu you will replace in eight months is expensive theater.

Build when three or more of these are true. Memberships are north of 20 percent of revenue and the true-up spreadsheet exists. You are at three or more locations, or crossing $4M, with cross-location redemption already causing arguments. Your injectables variance is unexplained and you have stopped investigating because you cannot. You have hired a person, or most of a person, whose job is moving data between systems. Your incumbent has told you the thing you need is on the roadmap, and the roadmap has moved twice.

Our position: the trigger is not size, it is the membership liability. The moment banked credit is a number your accountant asks about and you cannot produce it in one query, you have already outgrown the category. Everything else, scheduling, inventory, consults, is a problem you can suffer through. A liability you cannot measure is a problem that compounds.

How to choose a developer for med spa software

Ask them to whiteboard the membership credit data model before you sign anything. If they draw a balance field on the client record, they have never built this. You want to see an append-only ledger with accrual and redemption entries, price-snapshot fields, and location attribution. Thirty minutes of whiteboard tells you more than any case study deck.

Ask how they would model an open Botox vial. The right answer includes a lot number, an open timestamp, a remaining-unit count, a reconstitution deadline, and a required disposition at shift close. If they talk about decrementing inventory on charting, they are building a retail POS with a medical skin on it.

Ask for their PHI posture in specifics, not a HIPAA badge. Where do treatment photos live, who signs the BAA with that storage provider, what the audit log records, how the AI extraction step handles PHI, whether patient data touches a third-party model provider and under what agreement, and how access is scoped when a front desk employee at Chandler opens a Scottsdale patient. Vague answers here are disqualifying.

Ask what they will do with your existing data. A serious developer will want a Zenoti or PatientNow export in week one and will come back with a reconciliation report showing where the incumbent's numbers disagree with themselves before writing a line of application code. And confirm the contract puts the repository in your organization from the first commit, with your team holding admin. If ownership is a phase-two conversation, walk.