Case Study · Medical aesthetics clinic group · Richmond, Burnaby & North Vancouver
Anonymized Case — A medical-aesthetics clinic group in Richmond, Burnaby and North Vancouver: website rebuild, SEO/GEO and a custom AI CRM
A rebuilt website that more people find, a booking system that stays in place, and a custom CRM around it where AI does the repetitive work and people make the call.
The client is anonymized. Only architecture, workflow and delivery outcomes are shown — no client- or patient-identifiable information.
Overview
For a three-clinic medical-aesthetics group in Richmond, Burnaby and North Vancouver: a rebuilt website with SEO/GEO work (daily search clicks up 32% after the redesign), integration with the clinics' Zenoti booking system, and a custom AI-assisted CRM. Client anonymized.
Client: a dual-brand medical-aesthetics group with three clinics, in Richmond, Burnaby and North Vancouver, and 11,000+ active clients. Delivery: a rebuilt website with SEO and AI-search (GEO) work, integration with the booking system the clinics already use (Zenoti), and a custom AI-assisted CRM built around it.
The challenge
Three clinics, two brands, and the work spread across separate tools: bookings in one place, client notes and packages in another, spreadsheets for the rest. The same client and the same payment showed up in several places and rarely lined up. Catalog setup, packages, client notes, reconciliation and consent forms were typed by hand, and cash revenue was mixed with package and membership redemptions, so the reports overstated what came in. Online, the website needed to be found by more of the people searching for treatments nearby.
Our approach
Two tracks. First the website: rebuilt, with SEO and AI-search (GEO) work so the clinics show up both in search results and in AI answers. Second the operations: the clinics keep booking in Zenoti, and a custom CRM sits beside it, linked through an external-ID mapping, so clients, packages, notes and finances live in one place. AI does the repetitive steps; anything that matters passes a human review queue.
Results
Daily search clicks rose 32% in the period after the website redesign. The three clinics work from one CRM with 28+ modules that can be switched on as needed, cash and redemptions are booked separately so the reports match the bank, and master-data entry that used to take days takes minutes. Central inventory with automatic deduction per treatment is the next module and is still being planned.
The website: rebuilt, then found more often
The redesign and the search work went together. The site was rebuilt for both brands, with SEO done in the build itself and content written so AI search tools can quote it (GEO). Daily search clicks rose 32% in the period after the redesign.
Search results depend on many things outside anyone's control; this is what we measured for this client, not a forecast for another.
Booking stays in Zenoti; the CRM does the rest
We did not ask the clinics to change how they book. The CRM connects to Zenoti through an external-ID mapping table, so a client in the booking system and a client in the CRM are the same record. The core never depends on one vendor: booking, EMR and payment systems all attach the same way.
How AI works inside the CRM
Not a chat box in the corner — part of the daily work, with people signing off:
- Spoken catalog setup — a manager describes a new package in one sentence and AI turns it into a structured catalog entry, linked to services, devices, consumables and rooms. Days of data entry become minutes.
- Clinical paperwork drafts — the practitioner dictates; AI drafts the treatment record and aftercare notes, and consent forms are drafted per treatment. The practitioner reviews and signs.
- Client notes — high-value clients get a spend summary and follow-up suggestions written back to their profile.
- Task capture — paste meeting notes and AI extracts tasks, owners and milestones as Kanban cards.
- Client messages — multilingual drafts are generated, reviewed by a person, then sent.
- Speech-to-text — consultations and HR interviews are transcribed and archived, searchable.
- AI review of its own code — several AI agents audit each other's code and drive end-to-end tests; one pass found and fixed 42 defects in cross-clinic data isolation, financial accounting and concurrency.
Outcomes
- Daily search clicks +32% after the website redesign
- Three clinics on one CRM (28+ modules), owned by the client and changeable at any time
- Master-data entry: days → minutes (spoken setup)
- Cash and redemptions booked separately — reports that match the bank
- Per-clinic data isolation, hardened by several AI audit passes
- 2,000+ automated tests keep watch over every change
- Next: central inventory with automatic deduction per treatment (planned)
Technical breakdown
- Vertically sliced into 28+ modules by business capability: each module owns its tables (module-prefixed), APIs and pages; cross-module table access is banned — modules hold only foreign IDs and talk through public APIs and an event bus.
- Platform layer separated from business logic: auth/RBAC, multi-tenancy, a transactional event bus (outbox), audit, notifications, file storage and the AI gateway, reused by every module.
- No hard-coded client differences: variance lives in config options and extension points (events/hooks); field-level differences ride on core columns + JSONB custom fields.
- Financial integrity built in: cash collections and entitlement redemptions (packages, memberships, points, gift cards) are booked separately, and cash is counted exactly once across the purchase→redemption chain.
- Schema-driven clinical records: treatment types and form fields are template configuration (JSONB schema); signing locks the record with an immutable snapshot.
- External systems (Zenoti booking, EMR, payment gateways) attach through an external-ID mapping table plus optional sync extensions — the core never depends on a third party.
Reusable lessons
- Keep the tool the front desk already knows. Integrating with the booking system cost less, and changed less, than replacing it.
- A module boundary = whichever tables change together when one requirement changes. Slicing by that one test gave 28+ modules with no dependency cycles.
- Cross-module actions like merging client records become events: the owning module migrates its own tables and broadcasts; every other module re-points its rows by subscription.
- Embed AI as process-as-code: the process is code, the model fills the blanks, and critical actions pass a human review queue.
Want results like these?
Tell us about your business and we'll scope a paid proof of concept.