Med spa CRMs, compared by someone who does not sell one

Search for the best medical spa CRM and the first result is a page titled “12 top tools reviewed”, published by PatientNow, which concludes that PatientNow is the top pick. The second is also PatientNow. Further down, Pabau compares medical spa CRMs and recommends Pabau. Phorest, Cherry and Portrait all publish their own.

This is not dishonest, exactly. Everyone knows what a vendor comparison is. But it means the entire first page of results for a genuine purchasing question is written by people with an answer they need you to reach, and it explains why those comparisons all evaluate the same things: booking, charting, payments, marketing modules, pricing tiers. Those are the categories where the sponsoring vendor scores well.

We run these systems for clinics and sell none of them. So this covers the thing the vendor comparisons leave out, which happens to be the thing that decides whether you can ever prove your marketing works.

What each one says it is for

Taking the vendors at their own word, because their positioning is the most reliable thing about them:

PatientNow presents itself as the all-in-one for aesthetics: EMR, marketing automation and practice management in one platform, with clinical features like injection tracking and e-prescribing.

AestheticsPro leads on clinical documentation. SOAP notes, treatment plans, record keeping. The pitch is depth of compliance rather than breadth of marketing.

Zenoti is built for scale. Multi-site permissions, enterprise scheduling, analytics. It appears in comparisons aimed at groups rather than single locations.

Pabau positions as all-in-one across booking, records, payments and marketing.

Aesthetix CRM leads with marketing and integrations, listing native connections plus Zapier into tools like Aesthetic Record, Gravity Forms and Stripe.

Mangomint, Vagaro, Phorest and Jane sit closer to the booking and scheduling end, with Jane positioned as healthcare-general rather than aesthetics-specific.

That is positioning, not assessment. Every one of these has clinics running happily on it and clinics that regret the choice, and which group you land in has more to do with how you actually operate than with the feature list.

The question none of the comparisons ask

Can this system hold an advertising click identifier against a patient record, keep it attached through consultation and follow-up, and export it alongside the treatment value when they pay?

That is it. That single capability determines whether you will ever be able to say which advertising produced which revenue, and it is the prerequisite for uploading offline conversions at all. It appears in none of the comparison tables, because it is not a feature any vendor markets.

It matters because of how the money actually flows. Somebody clicks an ad, Google attaches an identifier to that click, and unless your CRM stores that string and gives it back to you later with a number beside it, the connection is gone. You will still have reporting. It will tell you how many leads arrived, which is the number that looks fine while the business feels wrong.

Only around 1% of healthcare marketing teams can currently tie more than half their spend to patient outcomes. The CRM is where most of them lose it, and it is step two of the four that close the loop.

Four questions for the demo call

Ask these before the feature tour. They take about five minutes and they sort the field faster than any comparison table.

1. Can I create a custom field on the patient record, and does it accept an arbitrary string of about a hundred characters?

This is where the click identifier lives. Most systems can do this. Some restrict custom fields to dropdowns and dates, which is a quiet no.

2. Does that field survive the full journey?

Ask specifically what happens when a lead is converted into a patient, when a record is merged with a duplicate, and when an appointment is rescheduled. Several systems create a new record at conversion and only carry across the fields they consider standard. Custom fields silently do not make the trip. This is the most common failure and the hardest to spot afterwards, because everything looks correct until you go looking for data that was never carried.

3. Can I export that field together with treatment revenue, on a schedule, without opening the interface?

Not “can I export a report”. Specifically: those two values, on the same row, on a recurring basis, reachable by an API or a scheduled file drop. If the honest answer is that someone runs a report manually each month, that is a process which will be abandoned by March.

4. What leaves the building, and can I control it?

Google Ads is not HIPAA compliant. The upload may carry the click identifier, an action name, a timestamp and a value, and nothing else. Ask whether you can control exactly which fields are included in an outbound integration. A system that only offers all-or-nothing sync to advertising platforms is a compliance problem, not a convenience problem.

Why there is no scorecard here

The obvious next move would be a table scoring each of these nine tools against those four questions. I am not publishing one, and the reason is worth stating.

I have not tested all nine. I have run some of these systems in production and read the documentation for others, and the difference between those two levels of knowledge is exactly where a comparison table becomes confidently wrong. Custom field behaviour on record conversion is not something you can determine from a features page. It is something you find out in month four, when the export comes back with an empty column.

Vendor capabilities also change every quarter. A scorecard published today is a liability by spring, and the internet is full of medical spa CRM comparisons still quoting prices and integrations from two years ago. Several of the pages currently ranking are in that condition.

A framework survives version changes. A matrix does not. So the four questions are the deliverable, and you should put them to the vendors directly and hold them to the answers, because they will answer them accurately when asked specifically and will not volunteer any of it.

If your current system fails the test

Most do, and changing CRM is expensive, disruptive and usually the wrong response.

There are two workarounds worth knowing. The first is a middleware layer: capture the click identifier at the form, store it in something you control alongside a reference to the CRM record, and rejoin the two at export. This is a small piece of engineering rather than a migration, and it is what we build most often, because the clinical side of the CRM is usually working fine and only the marketing plumbing is missing.

The second is to change what you upload. If the identifier cannot survive to the point of payment, upload an earlier milestone that it does survive to, valued at what that milestone historically produces. You lose precision and keep the signal, which is the right side of that trade.

The failure that shows up most often

A practice buys an all-in-one, and the marketing module includes a lead source dropdown. Google, Facebook, Referral, Walk-in, Other. Reception selects one when they create the record. Everyone agrees this is attribution and moves on.

Six months later the report comes back and roughly forty per cent of records say Other, a large block says Google with no way to distinguish paid from organic, and the referral figure is whatever the front desk remembered to click during a busy week.

The dropdown was never an attribution system. It is a survey filled in by somebody who was mid-conversation with a patient, and it degrades in exactly the way you would expect a manual field to degrade. It is also the single most common reason a clinic believes it has attribution and does not.

The tell is easy. If your lead source data is populated by a human choosing from a list, it is an opinion. If it is populated by a machine reading an identifier that came in with the click, it is a measurement. Only the second one can be checked. This is the same failure that makes 400 reported leads and 40 actual patients both true at once.

The all-in-one question

Every vendor in this category pushes toward all-in-one, and the argument is genuinely reasonable: one system, one support relationship, one place the data lives, no integration to maintain.

The argument against is equally real. In an all-in-one, the marketing module is almost always the weakest component. It exists so the platform can say it has one. It will do email, basic segmentation and a lead source dropdown, and it will not do the things a serious acquisition operation needs.

The deciding question is not which is better in the abstract. It is whether anyone owns integrations at your practice.

If nobody does, take the all-in-one and accept that the marketing module is mediocre, because a best-of-breed stack with no owner degrades into several systems that disagree with each other, which is worse than one mediocre system that agrees with itself.

If somebody does own it, whether that is an agency, a technical person internally or a partner, best-of-breed usually wins on the marketing side, because you can put a real CRM behind a good clinical system and route between them deliberately.

What migrating actually costs

Practices budget the licence and are surprised by everything else.

The licence is the smallest line. The real costs are historical data that does not map cleanly into the new schema, several weeks of running both systems while the team learns one and still relies on the other, every automation and integration rebuilt, and a reporting baseline that resets on the day you switch.

That last one deserves attention if you are trying to prove marketing works. Migrate in September and your year-on-year comparison is broken for twelve months, precisely while you are attempting to demonstrate that a change produced a result. If a migration is coming and it can wait for a quarter boundary or a financial year, wait.

None of which is an argument against changing systems. It is an argument for changing once, deliberately, having asked the four questions first, rather than changing twice because the first move solved the clinical complaint and created a marketing one.

What actually matters

If you are choosing a CRM today, the clinical fit should decide it. Whether your injectors will use it, whether charting works the way your practice charts, whether support answers. Those things determine daily life and no external framework improves on your own judgement there.

Attribution should be the tiebreaker rather than the criterion. Between two systems your team likes equally, take the one that answers those four questions cleanly, because that choice compounds for years and the other differences will not.

And if the demo cannot answer the four questions, that is itself information. Every one of these vendors knows exactly what a GCLID is. A salesperson who cannot tell you how their product handles one is telling you where it sits on their roadmap.