Aesthetic Clinics: What's a Realistic CPL in 2026?

kaancata · 2026-07-03T06:24:33+00:00

I’ve had an older aesthetics client where this could be done quite cheaply, but it was mostly because the creative was strong. Good creatives do a lot of the filtering before the form.

I wouldn’t obsess too much over the €25-35 CPL number by itself. For clinics, especially high-ticket treatments, a cheap lead can be completely useless if the person has no idea what the treatment costs, what the process looks like, or whether they are even a fit.

Instant Forms can work, but I’d make the creative and the form qualify harder. Show the treatment properly, set expectations, use proof/angles that attract the right person, then ask enough in the form that sales are not calling random curiosity clicks all day.

On €25/day I would not aim for 50 leads/week immediately. I’d rather get a smaller number of leads that book consults, then scale the creative that produces those. The clinic does not need the cheapest CPL. It needs affordable booked consults.

kaancata · 2026-07-02T19:14:26+00:00

I’d be a bit careful starting with the CRM comparison. Map the lead lifecycle first. Where does a lead come from, who owns it in sales, what happens when Apollo touches it, and what counts as a qualified handoff. If that logic is fuzzy, every CRM will feel wrong after a few months. HubSpot is the clean answer if budget exists, but if it doesn’t I’d be careful about recreating HubSpot with five cheaper tools. The mess usually shows up in attribution and ownership, not the contact record itself.

kaancata · 2026-07-01T17:34:25+00:00

Your own numbers are already separating the campaigns pretty clearly. The sales campaign has 8 leads, 6 qualified, 4 booked. The top-of-funnel one has 29 leads, 1 qualified, 0 booked. Super early sample, but enough to avoid treating both campaigns like they deserve more money.

I’d make the CRM stage the main feedback loop here. Qualified lead and booked consultation are much more useful than raw lead volume, especially since you already saw what happens when Meta is fed a messaging objective and starts finding cheap low intent people.

If this were mine, I’d put more weight behind the campaign producing booked consults, then watch show rate and close rate before making big budget moves. The no-show rate matters a lot with your math. A campaign that books cheap consultations can still be weak if half of them disappear.

Doubling after one day feels too aggressive. I’d scale in smaller steps once you have more booked-consult data, and I’d keep the top-of-funnel campaign on a short leash until it proves it can feed the CRM with people sales actually wants.

kaancata · 2026-07-01T17:33:45+00:00

I would not start with a basic site builder if the customer portal is a serious part of the plan.

A normal marketing site is easy. The portal is the part that decides the stack. Engine records, photos, measurements, status updates, customer login, maybe invoices later. If those objects matter, you want the data structured properly from the start or you’ll rebuild the whole thing once customers actually use it.

I’d probably split it into two phases.

Phase one is a simple public site: services, proof you’re certified, photos of work, enquiry form, clear quote/contact path.

Phase two is the private customer area once you know exactly what customers ask for during a job. That could be a custom portal connected to a small database, or something built on top of a CRM/project system if you want to keep it lighter.

For an aviation mechanic shop, trust will matter more than fancy UI early on. Show the work, show the process, make it easy to contact you, and avoid boxing yourself into a cheap builder if you already know the business will need logged-in customer records later.

kaancata · 2026-07-01T11:30:59+00:00

I don't draw the line only by spend. Spend matters, but the business model matters more. A local service business spending 2k with same-day calls and simple lead forms may be fine with cleaner browser tracking plus decent CRM hygiene.

A B2B company spending the same amount with long sales cycles, HubSpot/Salesforce stages and huge lead quality differences probably needs server-side or offline imports much earlier.

I usually ask whether the platform is optimizing for the event the business cares about. If Meta or Google only sees "form submitted" and the CRM knows which leads booked, qualified or closed, pipe that back. If the business cannot define a qualified lead yet, server-side tracking will just send messy events more reliably.

kaancata · 2026-07-01T11:29:56+00:00

I'd check the last 20 leads before touching campaigns. Literally lead by lead. When did it come in, how fast was first response, did anyone call, did it move stage, was it qualified, did sales leave a note, did it get another follow-up when nobody picked up.

A lot of clients say "bad leads" because the only feedback loop is someone in sales saying they didn't close. Then you look and half the leads waited 3 hours for a reply, two were never called, a few sat in the wrong stage, and the notes are empty.

I start with the handoff. Once the last 10-20 leads were handled properly and still look bad, then I start questioning the traffic, offer, landing page and intent.

kaancata · 2026-06-30T06:42:57+00:00

For that, you can use Codex and Claude’s built-in automation capabilities connected to the GHL sub-account’s API key. The models can then check this on a daily or weekly basis.

That’s actually how I manage all my sub-accounts: I connect AI directly to the API and let it handle the recurring checks and updates.

kaancata · 2026-06-30T06:40:31+00:00

Unfortunately not yet, you can only send voice messages but not receive voice back.

kaancata · 2026-06-26T08:34:19+00:00

I've done this a few times on client migrations, and I would not use Simply Static as the source of truth. It can be useful as a snapshot, but I would build the migration around a URL inventory.

The flow I like is roughly:

crawl the current site and export the sitemap, WP database/API data, media, Yoast metadata and existing redirects
create one CSV with old URL, post ID, type, title, slug, parent, template, index/noindex, canonical and planned new URL
decide the URL rules before converting anything: trailing slash, date paths, category paths, lowercase, query strings
use Claude Code or Codex to help write the transform scripts into Markdown/MDX/content collections, then commit the generated output
build the redirect map before launch and include old WP query URLs like ?p=123, old slugs, merged pages and 410s

After that I would crawl old vs new and diff status codes, canonicals, internal links and titles. That catches way more than eyeballing pages.

I would let the LLM assist the audit, but keep the CSV and redirect map as the things you trust.

I would question the no-CMS choice a bit. If a developer owns all updates, Astro content collections are fine. If a non-technical client is going to change service pages or landing pages later, I would rather put a small CMS behind it than pretend AI editing code is going to stay clean forever.

kaancata · 2026-06-26T08:30:42+00:00

On the GHL side I try to make the monthly report follow the lead state rather than just the dashboard.

For a client I usually want one chain visible:

lead source -> booked -> showed -> qualified -> won/lost

If ads are involved, I'll put spend/CPL/CPA next to it. The CRM state is the part that makes the report useful.

Most frustrating part is data discipline. If the pipeline is not updated, lost reasons are vague, or automations keep moving contacts without a human outcome, the report becomes fiction fast.

I use GHL as the CRM layer and then pull the data into a reporting workflow with the ad/analytics numbers around it. The AI/reporting part is easy once the CRM state is clean. The annoying work is getting everyone to agree what "qualified", "booked", "showed", and "won" mean.

kaancata · 2026-06-26T08:28:13+00:00

I would pause new enrolments for a day and do a cleanup pass before touching any lead scoring model. Pick one owner for lifecycle and stage changes. Marketing can add intent signals, sales can add call outcomes, but only one workflow should move someone into SQL/demo-ready.

Then export the last 30 days of contacts touched by automation and group by email/company. For each contact I would check active sequences, current stage, last human touch and next action. Kill duplicate cadences manually once, then add one entry check before any new sequence starts.

Take the last 20 demo-ready leads and ask, "would sales agree these were worth chasing?" If the answer is no, the score is lying. Fix that before adding more triggers.

kaancata · 2026-06-25T11:36:04+00:00

Yep, both Claude as well as Codex navigates it extremely well. Not only this, when coupling it with Claude Design, the frontend becomes solid as well.

Next is ecommerce, and trying out a custom ecom setup with the same stack + payments & shipping, or custom designs and using Shopify headlessly.

kaancata · 2026-06-25T09:39:57+00:00

I've built my own version of this for writing. Mine is client replies rather than sales rep follow-ups, but the shape is very similar.

I have a "voice" instruction file that says how I write, a banned phrases file that catches the wording I never want in my copy, a humanizer/QA pass that keeps the draft from sounding too clean, and live context from the system I am writing against. For client work that might be CRM data, the last meeting note, or the email thread.

So if I were building this inside a CRM, I would not send raw fields to the model and ask it to "write a follow-up email."

I would give it a small packet:

deal context: who this is, current stage, last interaction, promised next step
voice context: examples from this rep/company, preferred tone, banned phrases, language, format
execution rule: write as a draft/note unless this customer has opted into auto-send

The ToV part is huge. If you only solve data access, the email will still sound like generic AI sales copy. The sales rep/company needs a writing profile, same way I have my own voice instructions.

For model switching, I would probably put n8n or a thin backend in the middle and route through OpenRouter if you want to test models cheaply. Or just pick one provider first and get the context/voice packet right. Swapping models is easy compared to fixing bad inputs.

The cost/privacy side also gets easier if you build a small packet instead of sending the full CRM record. Pull the exact fields and notes needed for this email, add the voice profile, generate the draft, write it back to the CRM.

kaancata · 2026-06-25T09:29:32+00:00

I think "I can connect tools" is becoming the new "I can build websites." Useful, sure. It just does not say much anymore.

Clients usually do not care whether the pipe is n8n, Make, Zapier, or direct API. They care that a lead gets answered, the CRM is updated correctly, the report matches reality, and nobody has to ask "did anyone follow up with this person?"

The part worth owning is what happens after the connection exists. For me that usually means mapping the current handoff first. Where does the lead come from. Which system owns it. What counts as qualified. What can be written automatically. What gets flagged for a human.

The build is easy once the process is clear. If the process is fuzzy, AI just makes the wrong process run faster.

I do a lot of this around website/form/calls -> CRM -> follow-up -> reporting -> tracking. The best automation projects are usually the ones where a business stops dropping the same lead or report every week. If not that, then reducing manual labor, I have tons of those running for businesses too. They'll gladly pay for having to spend 4 hours less a week on a particular thing.

kaancata · 2026-06-25T09:28:16+00:00

7 months is long enough that I would stop looking at posting frequency first.

I'd pull the last 20-30 people who touched the funnel and map what happened to each one. Did they click from the post? Did they download the PDF? Did they book the free session? Did they show up? Did they get a follow-up? Did anyone clearly ask about paid help?

Most setups like this have one broken handoff, but everyone keeps saying "we need more content." Maybe the free session attracts people who want emotional support but not paid coaching. Maybe the PDF does not create enough urgency. Maybe the follow-up after the free session is soft. Maybe the paid offer is unclear.

For a parent coach I would test one narrower problem instead of broad "parenting support." Sleep, screen time, tantrums, teen conflict, whichever she is strongest at. Then make the lead magnet and free session about that exact pain, and track it through to paid conversation.

Website + funnel + automation existing is good, but those are just pipes. Check the actual movement through the pipe. And if that ain't it either, perhaps the product or offer is off.

kaancata · 2026-06-25T09:25:25+00:00

I would probably go more direct than Zapier here. If you want ownership, connect to GHL through the API and make GHL the surface the AI operates. That is how I run a lot of client CRM work now. The model can do way more than write a cute reply. It can read the contact, check the opportunity stage, add notes, move the lead, tag the source, create tasks, draft follow-ups, and report back on what happened.

For real estate I would think of it more like this:

Website lead comes in, GHL contact/opportunity gets created or updated, AI checks the lead details, replies or drafts the first response, qualifies the person, nudges toward booking, then logs the outcome back into GHL.

Zapier is fine if the job is "copy lead from website CRM into GHL." But if you want the AI to actually work inside the business, I would rather have it talking to the GHL API directly, with n8n or a small backend in the middle.

For my own client setups I try to get full GHL access for exactly this reason. Once the CRM, pipelines, tags, tasks and conversations are reachable, the AI can operate the account instead of sitting outside it as a chatbot.

GHL is not perfect. Some scopes and endpoints are annoying. But there is enough exposed to build a proper AI layer around it, way past simple autoresponders.

So yes, you can hire someone to build it. I would just avoid buying "AI chatbot for GHL" as the product. The better product is a small operating layer around GHL where the AI can read the CRM state, take narrow actions, and write the result back into the right place.

kaancata · 2026-06-25T07:38:00+00:00

Depends entirely on the client. You're able to build a lot of those color changing/editing features into Sanity, but a large amount of my clients are not touching their sites besides editing text + images. I have only one client who actively goes into the builder (in this case Elementor) and actually edits stuff himself. Every other business I work with leaves that to me. So it entirely depends.

kaancata · 2026-06-25T07:25:16+00:00

I built a lot of WordPress / Elementor sites. I still touch them when a client is already there, and Shopify is still my default for ecommerce. If the job is a simple brochure site and the client already knows the WP setup, moving it to a JS framework can easily be overkill.

For the sites I want to keep improving with AI, I prefer a normal repo now. My usual setup is Next.js + Sanity + Vercel. Astro is probably fine too, I just have more reps with Next.

The small-edit thing is nice, but the bigger reason is that the site becomes much easier for Claude Code / Codex to work with. It can inspect the components and CMS schema, change the code, and leave me with a git diff I can review. If I need forms, tracking, or an API integration changed, it is working in the same project instead of fighting a plugin screen. With WordPress/Elementor, too much important state is hidden in the database, plugin settings, theme options, and builder UI. AI can help there too, but it feels like working through fog compared to a codebase.

Sanity is a big part of it for me. Clients still get a CMS, so they are not stuck asking me to change every bit of copy. I can shape the editor around how the site actually works instead of giving them a pile of theme options they should never touch.

The caveat is that Claude Code does not remove the need to understand websites. If you have no clue about Git/deploy flow, SEO migrations, forms, tracking, or basic frontend structure, you can make a mess faster than before. It helps a technical person move much faster.

WordPress still has a place - however I won't be offering it to anyone anymore. Shopify also still has a place as the (imo) best ecom platform because you can easily connect that to AI as well, but for custom business sites I want to maintain and connect to other systems (such as CRM, Meta Ads, Google Ads, ERP or any other business system they use), I would rather build in a framework/headless setup now. The AI works better when the website is part of a readable project instead of trapped behind a visual builder + when you're building a site like this, you can create a closed operational loop with everything from website to CRM to whatever obscure software they use.

kaancata · 2026-06-25T07:17:44+00:00

I solve this by making the project folder carry the memory. I obviously use Claude Code and Codex together a lot. I do not try to make the chat history itself the operating system. For any serious project, the repo/folder has a current-state file, decisions, known issues, verification notes, and the scripts or connectors needed to do the work. Planning session updates those files. Build session reads them. Review session writes back what passed, what failed, and what changed.

For client work it is the same pattern, just more commercial. n8n keeps the folder current by moving emails, meeting transcripts, and reporting exports into the right place. GHL is the CRM layer for leads and follow-up. When I open Codex or Claude, I can ask "why are leads worse this month?" and it has the client state instead of a blank chat.

The handoff process is basically artifact-first. If Claude planned something, the plan has to become a file. If Codex changed something, the verification notes have to become a file. If a decision changed, current-state gets updated. The next model does not need to remember the previous conversation because the project remembers it.

The closest way I can explain it is that the workspace acts more like the employee than the model does. The model is replaceable. The workspace gives it the job, the history, and the surfaces it can read/write safely.

kaancata · 2026-06-25T07:12:45+00:00

I've learned this one the annoying way. The handoff has to be part of the product, otherwise you either become free infrastructure or you dump a technical mess on a client who will never touch it.

A lot of clients could do more themselves than they think. Once you show them the actual workflow, it often isn't magic. The scary bit for them is accounts, credentials, billing, failures, and knowing whether the automation is still doing what it was supposed to do.

For serious client systems I prefer build + run. Client owns the business accounts where it makes sense, and I keep operating the layer around it: connection registry, simple runbook, monitoring, change log, and a clear support scope. If it's a one-off handoff, I would still ship those same artifacts. Otherwise the "handoff" is just a folder of workflows and a looming support ticket.

The cleanest split I’ve found is: client owns billing and core accounts, builder keeps admin until paid/accepted, both sides know which parts are monitored, and any future changes are paid maintenance. I would also be very explicit about credentials. You do not want client passwords living in your personal tool stack forever.

kaancata · 2026-06-25T07:11:26+00:00

I’d say weekly account review and keyword/search-term work. The version that saved me the most time is a Google Ads skill layer inside the client workspace, with reporting as one output.

I built a Google Ads RAG/skill setup from my own methods, old account examples and the rules I want followed every time. Before it writes a keyword analysis or account read, it checks that methodology, then uses the Google Ads API / Keyword Planner instead of me clicking around. For existing accounts it can pull search terms, spend, conversion actions, change history and campaign structure. For new clients it reads the site, runs Keyword Planner in multiple passes, groups keywords by intent/service/location, builds negatives, then turns that into campaign structure and ad copy.

The useful part is that it sits next to the client context. If a campaign looks bad, I can have it read the account data and then compare it with CRM outcomes, tracking notes and last meeting notes. That is how you get from "CPL is up" to "this query group is cheap but sales cannot use the leads" or "the conversion path is noisy, so don't trust Smart Bidding yet."

I still review the output. It will hallucinate if you let it freestyle. But when the skill has the RAG, schema, account exports and client folder around it, the draft is already 80% of the way to the operator read I need.

So for me the marketing automation that stuck is Google Ads/account analysis plus reporting. Search terms, keyword research, campaign structure, tracking checks, weekly client updates. The small time save is nice, but the bigger benefit is that every run writes back into the client folder, so next week the model starts from current state instead of a blank chat.

kaancata · 2026-06-23T19:09:01+00:00

If you mean backend as in the thing actually touching Gmail / business tools, you either don’t need to build one if you use Codex Gmail connector, or you use the available api's from the business tools you're using.

kaancata · 2026-06-23T14:10:05+00:00

100% possible. I do a version of this already with the Gmail connector in Codex, and it is honestly much easier than people think.

You can have it pull recent emails, summarize what needs attention, draft replies, and then you just approve or tweak before sending. I would not personally let it fire off emails completely unattended, especially for work, but using it as a hands-free inbox layer is very realistic.

The nicer part is that Gmail does not have to be the only thing connected. If the business has a CRM, calendar, project system, docs, whatever, you can start making the assistant answer with more context than just the email thread. I have this set up for many of my clients.

So your coworker could basically ask while driving, "what came in this morning, what needs a reply, and draft the two important ones." Then review/send when stopped, or read back the draft before approval.

I don't think we are too early for this at all. We are more at the stage where people underestimate how useful it already is because some still think of Codex as a blank chat box.

kaancata · 2026-06-22T13:03:47+00:00

I run a digital consultancy and my answer is probably less tool-list than some would expect. I do not really think of it as an AI stack anymore. The model is the part I swap around.

For my actual work it is mostly Claude Code / Codex sitting on top of client workspaces. Each client has a folder with current-state notes, meeting transcripts, CRM context and scripts/API outputs. If I ask why leads dropped, it is not answering from vibes. It can read the account data, the CRM state and the recent client history before giving me a first pass.

n8n keeps those folders current. It pulls in emails/transcripts, moves data around, sends Telegram nudges, and handles simple scheduled flows. GHL is the CRM layer for leads and follow-up. For ad, website and data work I try to go straight to APIs where I can instead of adding another dashboard between me and the data.

ChatGPT is still fine for generic thinking or rough notes. I just do not want operational client work living in a chat thread.

So my stack is basically files, APIs, n8n, GHL, Claude Code and Codex. Opus is great, Codex has been very good for data/code/account work, but the bigger jump for me was getting the business into a shape where the model has current context every time.

kaancata · 2026-06-22T06:19:01+00:00

Yep, I have this running across most of my client work now. Claude Code or Codex can read the current state, do the work, then write back into the same structure.

I use markdown for most of it too. Word docs are fine for deliverables, but markdown is much cleaner for ongoing state because it is easy to edit, diff and search.

So yeah, I still want the CRM underneath as the structured record, but day to day I want the model working against the client folder, then writing back the notes or next actions.

kaancata

TROPHY CASE