AI Solution Architecture for a Med-Spa Chain Unifying Booking, CRM and Membership Data
Let's Connect
Overview
What we built
A 22-location med-spa group wanted one AI layer across booking, CRM and point-of-sale, but five vendors were each pitching their own architecture. We designed one reference architecture instead, and proved it by shipping the first AI use case on it.
In plain terms: this med-spa group had already centralised its booking, CRM, membership and point-of-sale systems across 22 locations, and wanted AI on top, things like predicting no-shows, flagging membership churn and timing campaigns better. The trouble was that five competing vendors each pitched their own architecture, assuming their own data pipeline, while client records sat duplicated across the existing systems. Nobody had even defined how protected health information would be handled by any of the models being proposed.
We designed a single reference architecture for the group instead of choosing between the five vendor pitches: an event pipeline unifying booking, CRM and point-of-sale data into one governed layer, tiered zones keeping identifiable health information separate from modelling data, a shared feature store and a standard model-serving pattern. We then proved the design by shipping the first use case, no-show risk scoring, on the new foundation within 9 weeks of approval, and the architecture is expected to cut integration effort for every future AI use case by roughly 40%.
The Problem
Five vendors, five architectures
The group had done real groundwork already, with booking, CRM, membership and point-of-sale systems centralised across all 22 locations, and leadership wanted to build on that foundation with AI: predicting no-shows, catching membership churn early and timing campaigns to the right clients. What it got instead was five different vendors, each convinced its own architecture was the answer.
Each of the five vendor proposals assumed its own data pipeline, which meant approving any one of them would have meant rebuilding client data flows around that vendor's assumptions rather than the group's own systems. Underneath the pitches, client records were already duplicated across the centralised systems, so even a single vendor's pipeline would have inherited the same inconsistencies.
The hardest gap was compliance. Nobody had defined how protected health information would be handled by any of the proposed models, which meant every one of the five proposals carried an open question serious enough to stall a signature. With no shared architecture and no agreed answer on health data handling, the group could not move on any of its AI ideas.
Five competing architectures
Five vendor proposals each assumed their own data pipeline, so choosing between them meant choosing which vendor's assumptions to rebuild the group's data around.
Duplicated client records
Client records were duplicated across the group's booking, CRM, membership and point-of-sale systems, undermining any single AI model's view of a client.
Undefined health-data handling
Nobody had defined how protected health information would be handled by any proposed model, leaving a compliance question unanswered in every vendor pitch.
Twenty-two locations, one decision
With booking, CRM, membership and point-of-sale already centralised across 22 locations, the group needed one architecture the whole network could build on, not five.
What it was costing them
Every month spent choosing between the five vendor proposals was a month the group's booking, CRM, membership and point-of-sale data stayed duplicated across systems, and a month closer to committing to one vendor's pipeline without a resolved answer on protected health information. Meanwhile no-show prediction, membership churn alerts and campaign timing all stayed ideas rather than tools, while the group kept paying for five parallel evaluations instead of one build.
The Solution
One governed AI reference architecture
Rather than picking a winner from the five vendor pitches, we designed a single reference architecture the group could own outright. At its centre sits an event pipeline that unifies booking, CRM and point-of-sale data into one governed layer, replacing the duplicated records spread across the existing systems.
Because protected health information was the unresolved question behind every vendor proposal, we built tiered zones directly into the architecture, keeping identifiable health information separate from the data used to train and run models. A shared feature store and a standard model-serving pattern mean every future AI use case, from no-show prediction to churn alerts, is built the same way rather than reinvented per vendor.
We proved the architecture rather than just documenting it, shipping the first use case, no-show risk scoring, on the new foundation. Approval to production took 9 weeks, and because the pipeline, tiers, feature store and serving pattern already existed, the group now expects roughly 40% less integration effort for every AI use case that follows.
Key decisions
One architecture, not five vendors
Instead of selecting among the five competing proposals, we designed a single reference architecture the group could apply to every future AI use case.
Unify data before modelling
The event pipeline unifies booking, CRM and point-of-sale data into one governed layer first, replacing the duplicated records the five vendor pipelines would each have inherited.
Separate health data by design
Tiered zones keep identifiable health information away from modelling data as a structural rule, resolving the question none of the five vendor pitches had answered.
Shared feature store for every use case
A shared feature store and standard model-serving pattern mean no-show prediction, churn alerts and campaign timing all reuse the same foundation.
Prove it with a real pilot
We shipped no-show risk scoring on the new architecture within 9 weeks of approval, so the design was validated by production use, not by review alone.
Measurable Impact
What changed after launch
The group now has one architecture instead of five competing proposals, with booking, CRM, membership and point-of-sale data from all 22 locations unified into a single governed layer. That resolves the duplication that sat under every vendor pitch and gives the group one place to build every future AI use case.
The first pilot, no-show risk scoring, shipped on the architecture within 9 weeks of approval, proving the design under real use rather than on paper. Because the event pipeline, tiered zones, feature store and serving pattern already exist, the group expects roughly 40% less integration effort for each AI use case it builds next.
Architecture
Five competing vendor proposals, each with its own pipeline
One approved reference architecture for the whole group
Client data
Duplicated across booking, CRM, membership and POS systems
Unified into one governed layer across 22 locations
Health data handling
Undefined in every vendor proposal
Tiered zones separate identifiable health data from models
AI delivery speed
No use case could move past the pitch stage
No-show risk scoring shipped within 9 weeks of approval
Headline results
5 disconnected vendor AI proposals replaced by one approved reference architecture
Booking, CRM, membership and POS data from all 22 locations unified into a single governed layer
First pilot, no-show risk scoring, shipped on the architecture within 9 weeks of approval
Estimated integration effort for each future AI use case reduced by roughly 40%
Tech & Tools Used
What powered the build
Every tool below earned its place in this engagement. Here is the part each one played.
AWS (S3, Glue, Lambda)
Provides the storage, batch processing and event-driven compute behind the reference architecture's unified data layer.
Snowflake
Holds the governed booking, CRM and point-of-sale data once it leaves the event pipeline, giving every future model one place to query from.
dbt
Models the governed layer's shared definitions, so no-show prediction and future use cases work from the same version of client data.
Apache Airflow
Orchestrates the event pipeline that unifies booking, CRM and point-of-sale data from all 22 locations into the governed layer.
Python (FastAPI)
Serves the no-show risk scoring model through the architecture's standard model-serving pattern.
scikit-learn
Trained the no-show risk scoring model that proved the reference architecture in production.
Redis
Backs the shared feature store, giving the no-show model and future use cases fast access to precomputed features.
Terraform
Provisions the reference architecture's infrastructure consistently, so each future AI use case inherits the same tiered zones and pipeline rather than a bespoke build.
Metabase
Gives the group visibility into the unified data layer and the no-show pilot's results without exposing identifiable health information.
Ready to Build your Medical Aesthetics & Wellness Business with AI Solution Architecture
Ask Byte
Ask Byte
Typically replies instantly
just Now
Hi! I'm OrganByte's assistant. How can I help you today?
AI-generated content may be incorrect
