Aesthetic Record and an AI receptionist: how the handoff works

The gap any practice management system leaves open

Aesthetic Record, like every platform in this category, is built around what happens once a client exists — charting, consents, before-and-afters, packages, memberships, inventory, checkout, reporting. All of that machinery is downstream of an event that happens somewhere else entirely: a person deciding to get in touch, and someone picking up.

That means the software is idle for every enquiry nobody answers. Your booking rate, your conversion reporting, your provider utilisation — all of it is measured after the moment where the leak actually happens. A practice can run a genuinely tight operation inside its platform and still lose a meaningful share of its inbound demand upstream of the tool that measures everything.

An AI intake layer sits in front of that gap. The question this page answers is what happens at the seam between the two: how much of what the agent captures actually lands in the platform, and how much lands in a human's inbox to be typed in.

Four levels of integration depth

These four are all described using the word "integration," which is why the word carries almost no information on its own. In ascending order of depth:

Two things are worth knowing before you assume level 4 is the goal.

First, levels 3 and 4 depend on what your account is actually permitted to do. API availability, which endpoints exist, what they allow to be written, and whether third-party access requires approval are decisions the platform vendor makes, and they can differ between plan tiers within the same product. No AI vendor can promise that access on your behalf, and any vendor who does is telling you something they are not in a position to know.

Second, level 4 is the most fragile of the four. A system writing appointments directly can create duplicate clients, book into the wrong service, or occupy a slot a provider needed — and unwinding that inside a live schedule is worse than having someone confirm. Most practices capture the large majority of the available value at level 1 or 2, because the expensive problem was never data entry. It was the enquiry going unanswered.

What each level really means in the clinic

Stripped of the vocabulary, here is what your front desk experiences on Monday morning under each level, after a Sunday-evening enquiry:

• Level 1. A text and an email are waiting, containing the caller's name, number, stated treatment interest, whether they are new or returning, and a link to the transcript. Someone opens the platform and creates the record. Elapsed effort: a couple of minutes, with no callback needed and no information lost.
• Level 2. The same information, but always in the same fields in the same order, so entry is mechanical rather than interpretive. This matters more than it sounds: consistency is what makes the task delegable and fast, and it is what makes the data usable for reporting later.
• Level 3. The enquiry is already sitting in a queue or sheet your team works from, alongside every other lead, with source and status attached. Someone still decides when it becomes a client record. This level is often the right stopping point, because it gets the operational benefit without handing write access to an automated system.
• Level 4. The client record and appointment already exist when your front desk opens the platform. The work becomes verification rather than creation. This is genuinely better when it works, and genuinely worse when the matching rules are wrong, which is why it goes last and starts with a human confirming every record.

What a usable client record needs

If the intake is not collecting the following, integration depth is irrelevant, because your front desk will call the client back anyway and you will have paid for an integration that saved nothing:

• Full name and a verified mobile number. Read back and confirmed on the call. Almost every downstream matching and messaging problem traces back to a mistyped number.
• New or returning status. This changes the entire path — a returning client often should go straight to booking rather than through a consultation flow, and creating a second record for them is the most common integration failure in aesthetics.
• Treatment interest, matched to your actual menu. Not a free-text guess. "Injectables" against a service you genuinely offer, so nobody is booked for something you do not provide.
• Stated goals in the client's own words. Captured verbatim in the transcript rather than compressed into a dropdown, so the provider sees what was actually said.
• Self-reported flags, logged not assessed. Pregnancy, recent procedures, or allergies a caller volunteers are recorded and flagged for your clinical team to review. The system never evaluates them, never advises, and never decides candidacy.
• Enquiry source. Which campaign, platform, or referral produced the lead, so your marketing reporting rests on intake data rather than assumption.
• Consent and contact preferences. Whatever your practice requires captured before follow-up messaging begins, in the form your practice specifies.
• Transcript and recording, attached. So the provider hears the original description rather than someone's summary of it.

Duplicate matching: phone first, then name

The moment any system can write records, duplicates become the main risk. In aesthetics this is worse than in most industries, because a duplicate record splits a client's treatment history, package balance, and membership across two entries — and the second record is often discovered by a provider mid-appointment.

A sane matching rule is ordered, not simultaneous:

1. Normalised phone number first. Strip formatting and country prefixes, then match. Phone is the strongest identifier in this context because it is unique, self-reported on the call, and confirmed back to the caller.
2. Then name, as a secondary check. A name match without a phone match is a candidate, not a match. Married and maiden names, nicknames, and transliterations all break naive name matching, and two people genuinely can share a name.
3. Then email, where captured, as a tiebreaker rather than a primary key — shared household emails are common enough to make it unreliable on its own.
4. Anything uncertain becomes a flagged item for a human, not a new record. This is the rule that matters. The correct behaviour on an ambiguous match is to hold the enquiry for review. If a vendor tells you their system "creates a new record" when it is unsure, that is the wrong answer and you should treat it as disqualifying.

Ask specifically what happens when someone calls from a partner's phone, or when a returning client's number has changed. Those two cases produce most real-world duplicates, and a vendor who has genuinely built this will have an answer ready.

Forms and DMs use the same four levels

Integration conversations default to phone calls, but for most aesthetics practices a large share of first contact arrives as a web form, a social message, or a text. The four levels apply identically to those channels — and the practical situation is often worse, because a form fill typically lands in an inbox nobody owns rather than on a line someone is responsible for answering.

• The capture step is easier. A form already produces structured fields. Whatever the enquiry is missing — treatment interest, new or returning, availability — can be gathered in a short follow-up exchange rather than reconstructed from a voicemail.
• The handoff step is identical. Notification, structured payload, middleware, or direct record creation. Nothing about the platform side changes because the enquiry arrived by text instead of by phone.
• The matching problem is slightly harder. A form fill may carry an email but a mistyped or absent phone number, which weakens the strongest matching key. Where phone is missing or unconfirmed, the enquiry should be held for review rather than written as a new record.
• Consent has to be captured before follow-up begins. Outbound messaging to prospective clients sits inside a real regulatory framework, and your practice's obligations are yours to determine. We build the mechanism to whatever consent and opt-out behaviour you specify; any vendor claiming their sequence is inherently compliant for your jurisdiction is claiming something they cannot know.

What it cannot do

Being specific about limits is more useful than a feature list:

• It cannot invent API access you do not have. If your plan does not expose it, or the platform vendor does not approve third-party access for your account, levels 3 and 4 are unavailable regardless of what any demo showed you. This is a commercial gate, not a technical one.
• It cannot give clinical advice. It does not assess candidacy for a treatment, discuss safety, contraindications, or expected outcomes. Anything a caller volunteers that touches on medical history is logged and flagged for your clinical staff, never evaluated.
• It cannot handle a complication. Anything that reads as a post-treatment concern leaves the booking flow entirely and escalates to your on-call provider. That path is built, tested, and signed off by your provider before anything goes live, and it never becomes a booking.
• It cannot resolve genuine ambiguity. A caller who is unclear, distressed, or describing something that does not map to a known service should be escalated, not guessed at.
• It cannot fix a capacity problem. If you are missing enquiries because your providers are already fully booked, faster intake produces a longer waitlist and a worse experience, not more revenue.
• It cannot make a bad record structure good. If your existing client data is full of duplicates already, an automated writer will match against a mess. Cleaning that up first is unglamorous and worth doing before level 4.

Questions to ask any vendor

Ask these of us and of anyone else you are evaluating. They separate a real integration from a screenshot:

1. Which of the four levels are you actually proposing for my account — not what is theoretically possible?
2. Does this require API access on my plan, who confirms that it exists, and whose job is it to obtain credentials?
3. Exactly which fields do you write, and which do you leave for my front desk?
4. What is your matching rule, in order, and what happens on an ambiguous match?
5. What happens to an enquiry if the integration is down — does it fail silently, or fall back to a notification?
6. Show me a record created by your system in a live account, not a demo environment.
7. Can I hear a recording of your agent handling a caller it did not understand?
8. If the platform changes its API, who does the remediation work and who pays for it?

The last two are the most revealing. Most vendors will not play you a recording of a failed call, and most have not thought about who owns maintenance when the platform changes underneath them.

A sane rollout order

The rollout that fails is the one that goes live on every call and writes records from day one. The one that works is narrow and reversible:

1. After hours, notification level. The agent covers evenings and weekends and texts your front desk. Nothing touches your practice management system. If it goes wrong, you have lost nothing you were not already losing to voicemail.
2. Structure the handoff. Once the transcripts read well for a couple of weeks, fix the format so entry becomes mechanical and consistent.
3. Add overflow. Let it catch the second simultaneous daytime call — still without writing records.
4. Add middleware, if it helps. Move the queue to wherever your team already works. Many practices sensibly stop here.
5. Consider direct record creation. Only if API access genuinely exists, and only with a person confirming every record for the first fortnight. Duplicates are cheap to prevent and expensive to unpick.

The same sequencing applies across the whole build, and the reasoning behind it is set out on the med spa lead response hub. The call-handling layer itself is covered on the AI receptionist page.

Common questions

Go deeper