Building a Robust Dental CRM: AlphaClinic's GoHighLevel Implementation

Most GoHighLevel briefs describe what someone hopes to build someday. This one is different. AlphaClinic — a growing Swedish dental clinic group specialising in general check-ups, implant consultations, and emergency visits — arrived with everything already designed: a 63-step setup guide covering three phases, a visual system blueprint spanning every pipeline, tag, field, automation, and integration, and clear operational requirements backed by real clinical workflow knowledge. The architecture was finished. The job was to build it — exactly as specified, without improvising, without cutting corners on GDPR, and without skipping the testing protocol that separates a working system from a good-looking one that breaks on day two.

What makes this build genuinely interesting is not the tool count. It is the constraint set. This is a Swedish client — EU data residency is not optional, it is legally required. The practice management system (Muntra) is Scandinavian-market software with an open API that most GHL freelancers have never touched. The end-users are dental receptionists, not marketing operations managers — the system has to be operationally intuitive, not just technically correct. And the expansion roadmap means every architectural decision must work for the first clinic and scale cleanly to the fifth.

This post documents the full build — not a summary, not a highlight reel. Every phase, every system component, every configuration decision — with the reasoning that makes the difference between a setup that holds together under real clinical volume and one that starts degrading by month three.

Why a Dental CRM, a Marketing Automation Platform, and a BI Layer Are the Same Problem

The most common mistake in healthcare CRM implementations is treating them as marketing projects. A GoHighLevel build for a dental group is not a marketing project. It is an operational infrastructure project that has marketing automation as one of its outputs. The distinction matters because it changes what gets built first, what gets tested most rigorously, and what the failure modes look like.

AlphaClinic sees three distinct patient types, each with a completely different journey through the system: the recall patient who had a check-up six months ago and needs a reminder to book again, the implant consultation lead who found the clinic through a Meta Ad and needs a nurture sequence before they are ready to book, and the emergency patient who has a toothache right now and needs a 15-minute response or they will call the next clinic in Google Maps. One platform. Three completely different workflows. They cannot share the same pipeline logic, the same lead routing, or the same automation triggers.

The integration architecture between GoHighLevel, Muntra (the practice management system), Make.com (the middleware), Meta Ads, Google Ads, and eventually Metabase is not a feature — it is the foundation. Without the Muntra sync, the recall automation has no patient data. Without UTM attribution flowing into GHL, the ad spend reporting has no denominator. Without the master snapshot architecture, the second clinic deployment takes weeks instead of hours.

"A GoHighLevel setup for a multi-location dental group is not a marketing project. It is an operational infrastructure build. Every pipeline, every automation, every field naming convention either serves the clinical workflow or creates friction against it. There is no neutral middle ground." Arsalan Faysal — Revenue Systems Architect

Phase 1 — Foundation: Building the Infrastructure That Everything Else Runs On

Phase 1 is the most consequential phase of the entire project. Not because it is the most technically complex, but because every mistake made here compounds through Phases 2 and 3. A custom field named incorrectly in Phase 1 is misreferenced by every automation in Phase 2. A pipeline built without the template-and-copy model in Phase 1 means every new clinic in Phase 3 gets a manual rebuild. Phase 1 is not setup. It is foundation engineering.

Agency Account Setup and EU Data Residency — The Non-Negotiable First Step

Before any sub-account is created, before any field is defined, before any pipeline is touched: EU data residency must be confirmed in writing, and the Data Processing Agreement (DPA) must be in place. This is the clinical-legal requirement that sits above every other technical requirement in the brief. Under GDPR Article 28, any data processor handling personal data on behalf of a Swedish clinic — including appointment history, patient contact details, and health-adjacent communication records — must provide a signed DPA and must store data in a jurisdiction that meets EU adequacy standards.

GoHighLevel's EU data residency option is available on the Unlimited plan and above. It routes all data storage to EU-region servers. The confirmation of this configuration must be documented — a screenshot of the data region setting combined with the executed DPA forms the written confirmation the brief requires before any patient data is imported. This is not bureaucratic overhead. It is the legal basis on which the entire patient data workflow rests.

Multi-Clinic Sub-Account Architecture

The fundamental architectural decision for a multi-location healthcare group in GoHighLevel is sub-account structure. There are two models, and choosing the wrong one creates a rebuild at the worst possible moment — when the second or third clinic comes online.

Model A: One sub-account per clinic. Each clinic location gets its own GHL sub-account. Contacts, pipelines, automations, and calendars are siloed by clinic. This is the correct model when clinics operate independently, have different staff, and need separate reporting and separate branding.

Model B: One shared sub-account with location-based segmentation. All clinics share a single sub-account. Location is tracked via a custom field on the contact record. Pipelines and automations use location-based conditional logic.

For AlphaClinic, Model A is the correct architecture — for three specific reasons. First, each clinic has separate reception staff who should only see their own patients and their own calendar. Second, GDPR data minimisation principles favour segmentation — a receptionist at Clinic A should not have access to Clinic B's patient records without a documented legitimate interest. Third, the master snapshot model (Phase 3) only makes sense in a sub-account-per-clinic architecture — you snapshot one clinic, deploy it as the template for the next one.

MULTI-CLINIC SUB-ACCOUNT STRUCTURE
──────────────────────────────────────────────────────────────────

AGENCY LEVEL (admin access — GHL Unlimited Plan, EU Region)
 │
 ├── AlphaClinic [Clinic 1] — Sub-Account
 │     Users: Clinic Manager, Reception Staff (2–3)
 │     Permissions: Full access to own sub-account only
 │     Billing: Agency-managed
 │
 ├── AlphaClinic [Clinic 2] — Sub-Account
 │     Users: Clinic Manager, Reception Staff
 │     Permissions: Full access to own sub-account only
 │
 ├── [Future Clinic N] — Deployed via Master Snapshot
 │     Deployment time target: under 1 business day
 │
 └── AlphaClinic MASTER (internal only — do not activate for production)
       Purpose: Snapshot source for new clinic deployments
       Users: Agency admin only
       Note: Never use this sub-account for live patient data

USER ROLES PER SUB-ACCOUNT
  Agency Admin:       Full access across all sub-accounts
  Clinic Manager:     Full access within own sub-account; can view
                      reports, manage staff users, approve automation changes
  Reception Staff:    Access to Contacts, Calendar, Conversations, 
                      Smart Lists only — no access to Automations,
                      Settings, or Reporting
  Marketing User:     Access to Funnels, Automations, Reporting —
                      no access to patient contact records directly

The Custom Field Library — 20 Fields Across 3 Categories

GoHighLevel's native contact fields cover the basics. For a dental clinic operating a multi-treatment, multi-source lead system, the native fields are insufficient for the routing logic, the recall automation, and the reporting that Phase 2 and Phase 3 require. The custom field library is built in Phase 1 because every automation in Phase 2 references these fields. Building them out of order means debugging automations that fire against fields that do not exist yet.

The 30-Tag System — Governance Through Naming Convention

Tags in GoHighLevel are free-form text — which means they become a chaos system within weeks if naming conventions are not enforced from day one. The 30-tag system for this build uses a strict prefix taxonomy that makes every tag self-describing, sortable, and auditable. The naming convention: [CATEGORY]_[descriptor] — all lowercase, underscores only, no spaces, no special characters.

Pipeline Architecture — The Template + Copy Model

The pipeline architecture uses six pipelines: three treatment pipelines and three operational pipelines. The critical design principle is the template + copy model: the master sub-account (created in Phase 3) contains the canonical pipeline configurations. Each new clinic deployment copies these pipelines exactly. Stages, field dependencies, and automation references are preserved in the copy — which means a new clinic's pipeline is wired to all the correct automations from day one.

PIPELINE OVERVIEW — 6 PIPELINES
──────────────────────────────────────────────────────────────────

TREATMENT PIPELINES (patient journey — booking to treatment)

1. IMPLANTAT (Implant Consultation Pipeline)
   New Inquiry → Nurture → Consultation Booked → Consultation Held
   → Treatment Plan Sent → Treatment Booked → Treatment Complete
   
   Notes: Longest pipeline — implant decisions take weeks to months.
   Nurture stage is where the majority of leads sit. The implantat
   funnel (Phase 2) feeds this pipeline as its primary lead source.

2. ALLMÄN KONTROLL (General Check-Up Pipeline)
   New Lead → Booking Initiated → Booked → Confirmed → Attended
   → Recall Scheduled
   
   Notes: Highest volume pipeline. Recall Scheduled stage is the 
   bridge to the 6-Month Recall Sequence. Booking is primarily
   through the embedded calendar — most leads move from New Lead
   to Booked within the same session.

3. AKUTTANDVÅRD (Emergency Visit Pipeline)
   Emergency Inquiry Received → Reception Notified (auto)
   → Patient Called → Appointment Booked → Visit Complete
   → Follow-Up Scheduled
   
   Notes: Separate fast-path pipeline. Emergency contacts NEVER
   enter the standard treatment pipelines — they route here
   exclusively. The 15-minute response protocol is enforced by
   SLA automation in this pipeline.

OPERATIONAL PIPELINES (internal management — not patient-facing)

4. LEAD MANAGEMENT (Inbound Lead Qualification)
   New → Attempting Contact → Contacted → Qualified → Disqualified
   
   Notes: Used for inbound leads that need qualification before
   being moved to a treatment pipeline. Meta Ads and Google Ads
   leads enter here first. Speed-to-Lead automation fires when
   a lead enters this pipeline.

5. RECALL OPERATIONS (Recall Campaign Management)
   Recall Due → Recall SMS Sent → Recall Email Sent → Responded
   → Booked → No Response (Churned)
   
   Notes: Operational view for reception to see which patients
   are in each stage of the recall cycle. Not patient-visible.
   Smart Call List for recall outreach is generated from this pipeline.

6. REPUTATION & REVIEWS (Post-Visit Engagement)
   Visit Complete → Review Request Sent → Review Given → No Response
   
   Notes: Feeds the Google Review Collection workflow. Simple
   pipeline — most contacts move through in under 7 days.
   Tied to Google Business Profile for review count monitoring.

Emergency Visit Routing — The 15-Minute Response Protocol

Emergency dental patients are time-critical in a way that no other lead type is. Someone with acute dental pain does not browse options — they call the first number that answers or fills the first form that looks responsive. The 15-minute response protocol is not a marketing goal. It is a clinical operations requirement, and the automation that enforces it must be airtight.

EMERGENCY ROUTING WORKFLOW — TRIGGER TO RESPONSE
──────────────────────────────────────────────────────────────────

TRIGGER: 
  Form submission tagged trt_emergency
  OR inbound call to emergency phone number
  OR social DM containing keywords: akut / tandvärk / smärta
  OR Google Ads "emergency dentist" campaign lead form

STEP 1 — IMMEDIATE (0:00 — within 60 seconds of submission):
  → Tag contact: trt_emergency + src_[channel]
  → Move contact to AKUTTANDVÅRD pipeline — Stage: Emergency Inquiry Received
  → Send patient automatic SMS (Swedish):
     "Hej [Förnamn], vi har fått din förfrågan och en av våra tandläkare 
      kontaktar dig inom 15 minuter. Vid svår smärta, ring oss direkt: 
      [kliniktelefon]."
  → Send PUSH NOTIFICATION to on-duty reception (GHL mobile app)
  → Send SMS alert to clinic manager: "AKUT LEAD — [Kontaktnamn] — 
     ring inom 15 min"

STEP 2 — 5 MINUTES (if no reception action logged):
  → Second push notification to reception
  → Email alert to clinic manager with contact details

STEP 3 — 15 MINUTES (if still no outbound call logged):
  → Escalation SMS to clinic manager + backup contact
  → Pipeline stage auto-advances to: ESCALATED (triggers dashboard flag)
  → Slack/email alert to agency admin (for monitoring)

STEP 4 — RECEPTION CALLS PATIENT:
  → Reception logs call outcome in GHL contact record
  → If booked: pipeline moves to Appointment Booked
               → Booking Confirmation SMS fires automatically
  → If not reached: pipeline moves to Patient Called — No Answer
                   → Retry call in 20 minutes (task created for reception)
  → If patient found alternative: tag status_churned_emergency
                                  → no further automation fires

EXCEPTION HANDLING:
  → If clinic is closed (outside business hours): 
    Emergency SMS includes out-of-hours guidance + next available slot
  → If all reception unavailable: auto-escalation to manager mobile

Booking Calendars, Ad Integrations, and Social Inbox

GoHighLevel's calendar system needs three distinct calendar configurations for AlphaClinic — one for each major treatment type. These are not the same calendar with different availability blocks. They are separate calendar entities because each treatment type has a different appointment duration, a different booking confirmation sequence, and a different post-booking pipeline stage assignment.

Meta Ads + Google Ads lead integration is configured through GHL's native Facebook Lead Ads and Google Lead Form integrations. The critical configuration step that most setups skip: UTM parameter preservation. GHL's default Facebook Lead Ads integration does not automatically capture UTM parameters from the ad. A hidden field mapping must be configured in the GHL form settings — mapping the utm_campaign, utm_content, and utm_source values from the landing page URL to the corresponding custom fields on the contact record at form submission.

For Google Ads: GCLID (Google Click Identifier) capture is enabled in GHL's Google Ads integration settings. The GCLID is stored on the contact record and passed back to Google Ads via the conversion import — this creates the closed-loop attribution that allows Google's algorithm to optimise for actual booked appointments, not just form fills.

Social media unified inbox connects Facebook Page DMs and Instagram DMs into GHL's conversations panel. Both accounts are connected at the sub-account level. Quick reply templates (minimum 8 Swedish-language templates) are configured for the most common reception scenarios: new inquiry acknowledgement, appointment availability check, emergency routing response, review request follow-up, and recall inquiry. Templates use GHL's merge fields to personalise with and variables.

Phase 2 — Automation & Content: The System That Runs the Clinic Between Appointments

Phase 1 built the infrastructure. Phase 2 is where it comes alive. The six core automation workflows are the operational centre of the entire build — they handle everything from the first second a new lead enters the system to the sixth month when a patient is due for their next check-up. This section documents each workflow in full: trigger, logic, branching, edge cases, and testing protocol.

Muntra → GHL Sync via Make.com — The Integration Architecture

Muntra is a Swedish dental practice management system. It is not a marketing platform, and it was not built with CRM integration in mind. What it does have is an open API — which is what makes the Make.com sync possible. The integration architecture has three components that must be built and tested in sequence, because each one depends on the previous one working correctly.

MUNTRA → GHL SYNC ARCHITECTURE — MAKE.COM SCENARIOS
──────────────────────────────────────────────────────────────────

SCENARIO 1: DAILY PATIENT DATA PULL (scheduled — runs 06:00 CET daily)
  
  Step 1: Authenticate with Muntra API
    → OAuth2 client credentials flow
    → Access token cached and refreshed automatically by Make.com
    
  Step 2: Pull updated patient records (modified in last 24 hours)
    → Muntra API endpoint: GET /patients?modified_after=[yesterday_ISO8601]
    → Fields pulled: patient_id, name, email, phone, 
      last_appointment_date, next_appointment_date, 
      appointment_type, treatment_history, no_show_count
    
  Step 3: For each patient record — search GHL for matching contact
    → Match by: muntra_patient_id (primary)
    → If no muntra_patient_id match: secondary match by email + phone
    → If no match: create new GHL contact
    
  Step 4: Update GHL contact fields
    → Map Muntra fields to GHL custom fields
    → Set last_appointment_date, next_appointment_date, no_show_count
    → Calculate recall_due_date = last_appointment_date + 183 days
    → Set appointment_type from Muntra appointment type mapping
    
  Step 5: Trigger recall check
    → If recall_due_date is within 30 days AND recall_sequence_enrolled = false:
      → Add tag: status_recall_due
      → Enrol contact in 6-Month Recall Sequence
      
  Error Handling:
    → HTTP 4xx errors: log to Make.com error log, skip record, continue
    → HTTP 5xx errors (Muntra server error): pause scenario, 
      send email alert to admin, retry after 1 hour
    → Field mapping failures: log contact ID + error, skip, continue
    → Duplicate GHL contacts found: log for manual review, 
      do NOT create duplicate — flag for dedup audit

──────────────────────────────────────────────────────────────────

SCENARIO 2: REAL-TIME APPOINTMENT WEBHOOK (event-driven)
  
  Trigger: Muntra webhook on appointment_created or appointment_updated
    → Muntra sends POST request to Make.com webhook URL
    → Payload includes: patient_id, appointment_id, appointment_type,
      appointment_date, appointment_duration, status
    
  Step 1: Parse webhook payload
  Step 2: Find matching GHL contact by muntra_patient_id
  Step 3: Update next_appointment_date + appointment_type
  Step 4: If status = "cancelled": set appointment_cancelled flag = true
          → Trigger no-show re-engagement check (if cancellation < 2h before)
  Step 5: If status = "completed": update last_appointment_date
          → Set recall_due_date
          → Enrol in Google Review Collection workflow

──────────────────────────────────────────────────────────────────

SCENARIO 3: NO-SHOW SYNC (runs 3 hours after each scheduled appointment)
  
  Step 1: Pull appointments scheduled for today from Muntra
    → Filter for status = "no_show" or patient absent with no cancellation
  Step 2: For each no-show: find GHL contact
  Step 3: Increment no_show_count by 1
  Step 4: Add tag: status_no_show
  Step 5: If no_show_count >= 2: enrol in No-Show Re-Engagement Workflow
  Step 6: Deduct 15 points from lead_score

The Six Core Automation Workflows — Full Technical Specification

Workflow 1: Speed-to-Lead

Speed-to-Lead is the highest-ROI automation in the entire build. Research consistently shows that response time within 5 minutes of a form submission increases conversion to contact by 9x compared to a 30-minute response. For a dental clinic competing with other local clinics who are all visible in the same Google Maps pack, this window is even tighter.

WORKFLOW: SPEED-TO-LEAD
──────────────────────────────────────────────────────────────────

TRIGGER: New contact created via:
  → Meta Ads lead form (excluding trt_emergency — emergency has own workflow)
  → Google Ads lead form
  → GHL funnel form submission (Implantat or Allmän kontroll pages)

STEP 1 — IMMEDIATE (0:00 — within 60 seconds of submission):
  → Send SMS to patient (Swedish):
    "Hej [Förnamn]! Tack för ditt intresse. Vi kontaktar dig inom kort 
     för att boka din tid. Med vänliga hälsningar, AlphaClinic [Klinik]"
  → Add tag: seq_speed_to_lead
  → Move to LEAD MANAGEMENT pipeline — Stage: New

STEP 2 — IMMEDIATE (parallel — notify reception):
  → Send internal notification (GHL notification to reception user):
    "Ny lead: [Kontaktnamn] — [Behandlingsintresse] — Källa: [src_tag]
     Svara inom 5 minuter."
  → Create task for reception: "Ring [Kontaktnamn]" — due in 30 minutes
  → If business hours (Monday–Friday 08:00–17:00):
      → Move to Stage: Attempting Contact
    If outside business hours:
      → Send additional SMS to patient:
        "Vi har stängts för kvällen men kontaktar dig första saken imorgon 
         bitti. Ha en bra kväll!"
      → Schedule reception notification for 08:00 next business day

STEP 3 — 2 HOURS (if no call logged by reception):
  → Second internal notification to reception
  → Escalation to clinic manager

STEP 4 — 24 HOURS (if still no contact attempt):
  → Manager escalation email with full contact details
  → Pipeline stage auto-flag: Overdue (dashboard indicator)

STEP 5 — 72 HOURS (if patient never reached):
  → Send follow-up SMS:
    "Hej [Förnamn]! Vi har försökt nå dig angående din förfrågan. 
     Är du fortfarande intresserad av att boka tid? Klicka här för 
     att välja en tid som passar dig: [Bokningslänk]"
  → Send follow-up email with same content + clinic information

STEP 6 — 7 DAYS (if no booking after follow-ups):
  → Set dead_lead_flag = true
  → Enrol in Dead Lead Resurrection sequence

Workflow 2: Missed Call Text-Back

When a patient calls the clinic and nobody answers, that patient's next action is calling the next clinic. The Missed Call Text-Back workflow fires within 30 seconds of a missed call, converting a dead-end phone interaction into an open conversation thread.

WORKFLOW: MISSED CALL TEXT-BACK
──────────────────────────────────────────────────────────────────

TRIGGER: Inbound call to GHL phone number — call status = missed

STEP 1 — 30 SECONDS:
  → Identify caller: search GHL contacts by phone number
  → If existing contact: personalised SMS with first name
    "Hej [Förnamn]! Vi missade ditt samtal. Kan vi hjälpa dig? 
     Svara på detta meddelande eller ring oss på [kliniktelefon]. 
     Eller boka direkt: [Bokningslänk]"
  → If unknown caller: generic SMS
    "Hej! Du ringde AlphaClinic men vi missade ditt samtal. 
     Kan vi hjälpa dig? Ring oss på [kliniktelefon] eller 
     boka online: [Bokningslänk]"
  → Add tag: seq_missed_call_tb

STEP 2:
  → Create task for reception: "Återring [Nummer/Namn]" — due 30 minutes
  → Internal notification to reception

STEP 3 — IF PATIENT REPLIES TO SMS:
  → GHL Conversations panel receives reply
  → Auto-assign conversation to on-duty reception user
  → If AI chatbot enabled (Phase 3): trigger AI response flow first

NOTE: This workflow does NOT fire for:
  → Calls made by reception outbound (only inbound missed calls)
  → Numbers on the internal staff list
  → Numbers with gdpr_opted_out = true

Workflow 3: Booking Confirmation & Reminders

The Booking Confirmation and Reminder workflow is a sequenced communication chain that fires from the moment a booking is made until 1 hour before the appointment. The no-show rate reduction effect of well-timed appointment reminders in dental settings is consistently documented at 25–40% — this workflow is directly tied to clinical capacity utilisation, not just marketing polish.

Workflow 4: 6-Month Recall Sequence

The 6-Month Recall Sequence is the highest-volume automation in the build by number of contacts processed — every existing patient with a completed appointment passes through it twice a year. The trigger is the recall_due_date custom field, populated by the Muntra sync. The sequence must be designed to handle three scenarios: patients who book on the first message, patients who need multiple touches, and patients who are genuinely unavailable and should not be harassed.

WORKFLOW: 6-MONTH RECALL SEQUENCE
──────────────────────────────────────────────────────────────────

TRIGGER: recall_due_date = TODAY (checked daily at 09:00 CET)
         AND status_recall_due tag applied
         AND communication_opt_out = false
         AND gdpr_consent_confirmed tag present

DAY 0 — FIRST TOUCH (SMS — high open rate for appointment-type messages):
  "Hej [Förnamn]! Det är dags för din halvårskontroll hos AlphaClinic. 
   Boka din tid enkelt här: [Bokningslänk]. 
   Mvh, AlphaClinic [Klinik]"

IF BOOKED after Day 0 → EXIT SEQUENCE. Add tag: seq_recall_complete. 
                       Move to ALLMÄN KONTROLL pipeline.

DAY 3 — SECOND TOUCH (Email — more space for context and clinic branding):
  Subject: "Dags för din tandläkarkontroll, [Förnamn]"
  Content: Personal greeting, reminder of why regular check-ups matter,
           clinic photos/team introduction, easy booking link + 
           phone number alternative.

IF BOOKED → EXIT SEQUENCE.

DAY 7 — THIRD TOUCH (SMS — final personal outreach):
  "Hej [Förnamn]! Vi vill bara påminna om din kontroll. 
   Inga lediga tider som passar? Ring oss så löser vi det: 
   [Kliniktelefon]. Eller boka när det passar dig: [Bokningslänk]"

IF BOOKED → EXIT SEQUENCE.

DAY 14 — SMART CALL LIST ENTRY:
  → Contact added to "Recall — Ej Bokat" Smart Call List
  → Reception can see this list, call patients directly from GHL
  → Call outcome logged: Booked / Not Interested / Wrong Number / 
    No Answer (try again in 7 days)

DAY 30 — FINAL EMAIL (for contacts never reached):
  Subject: "Vi saknar dig, [Förnamn]"
  Content: Low-pressure re-engagement. Option to opt-out of 
           recall reminders. Rebooking link. Phone number.

DAY 60 — IF NO ENGAGEMENT AT ALL:
  → Remove tag: status_recall_due
  → Add tag: status_churned (if last appointment was >18 months ago)
  → Enrol in Dead Lead Resurrection sequence (modified version)
  → Add tag: seq_recall_complete

Workflow 5: Google Review Collection

For a local dental clinic, Google reviews are a direct driver of new patient acquisition. A clinic with 4.8 stars and 180 reviews wins more walk-in and search-driven bookings than a competitor with the same location and similar pricing but only 40 reviews. The review collection workflow fires automatically post-appointment — the timing is calibrated to hit patients at peak satisfaction before the appointment fades from memory, but not so immediately that it feels automated and impersonal.

WORKFLOW: GOOGLE REVIEW COLLECTION
──────────────────────────────────────────────────────────────────

TRIGGER: Muntra webhook — appointment status = completed
         OR Make.com scenario marks last_appointment_date = today

GATE CHECKS (before any review request fires):
  → appointment_type ≠ emergency (no review requests for emergency visits
    — too high emotional stakes, not appropriate)
  → communication_opt_out = false
  → review_given_google tag NOT already present (never ask twice)
  → no_show_count was 0 for this appointment (patient actually attended)

T+4 HOURS (same day — while experience is fresh):
  SMS: "Hej [Förnamn]! Tack för ditt besök hos oss idag. 
        Hur upplevde du ditt besök? Vi uppskattar om du tar 
        2 minuter och lämnar ett omdöme: [Google Review-länk]
        Tack så mycket! /Teamet på AlphaClinic [Klinik]"

IF review link clicked → Add tag: review_given_google
                       → EXIT WORKFLOW (do not send email)

T+2 DAYS (if no click on review link):
  Email: Subject: "Tack för ditt besök, [Förnamn] — berätta hur det gick"
  Content: Personalised thank-you from the treating dentist (name 
           personalised if dentist info available from Muntra), 
           reminder of next steps (recall date), and Google review 
           request with direct link.
  → Add tag: seq_review_requested

NO FURTHER FOLLOW-UP — two touches maximum for review requests.
Patient satisfaction review requests that become harassment convert 
goodwill into annoyance.

Workflow 6: Dead Lead Resurrection

Dead leads are not lost leads — they are leads whose timing was wrong the first time. The Dead Lead Resurrection sequence re-engages contacts who went cold after initial inquiry, without spamming contacts who have genuinely disengaged. The sequence uses a different value proposition than the original Speed-to-Lead messaging — it leads with social proof, an offer, or a different angle rather than repeating the same booking request that already didn't work.

WORKFLOW: DEAD LEAD RESURRECTION
──────────────────────────────────────────────────────────────────

TRIGGER: dead_lead_flag = true
         (set by Speed-to-Lead workflow after 7 days no engagement,
          or by Recall Sequence after 60 days no response)

GATE CHECKS:
  → communication_opt_out = false
  → Contact has not previously completed resurrection sequence
  → Last contact attempt was ≥ 7 days ago

WEEK 1 — SOCIAL PROOF ANGLE (Email):
  Subject: "[Förnamn], vad tycker våra patienter om AlphaClinic?"
  Content: 2–3 genuine patient testimonials (GDPR-compliant — 
           first name + treatment type only). 
           Star rating graphic. Booking link. No pressure language.

WEEK 2 — VALUE ANGLE (SMS):
  "[Förnamn], visste du att vi erbjuder flexibla tider, 
   inklusive tidiga morgnar och kvällar? 
   Boka när det passar dig: [Bokningslänk]"

WEEK 3 — DIRECT ANGLE (Email):
  Subject: "Hej [Förnamn] — har du hittat en annan tandläkare?"
  Content: Honest, direct email. Asks if they found another clinic 
           (include option to opt out). If still interested — 
           "vi hjälper dig att boka enkelt."

WEEK 4 — FINAL TOUCH (SMS):
  "[Förnamn], detta är vårt sista meddelande. 
   Om du vill boka en tid, är vi alltid här: [Kliniktelefon].
   Svara NEJ om du inte vill ha fler påminnelser."
   
  → If patient replies NEJ: set communication_opt_out = true
                            Add tag: gdpr_opted_out
                            Exit all sequences permanently
  
AFTER WEEK 4 — NO ENGAGEMENT:
  → Add tag: status_churned
  → Remove from all active Smart Lists
  → Archive from active reporting (retain data — never delete)
  → Add tag: seq_resurrection_complete

The Implantat Funnel and the Allmän Kontroll Funnel

The two treatment-specific funnels serve fundamentally different buyer psychology — and this must be reflected in the design, copy, and CTA architecture of each page.

The Implantat funnel is for a high-consideration, high-cost treatment decision. A patient considering dental implants has typically been thinking about it for months, has probably Googled costs, and needs to feel that the clinic is credible, experienced, and trustworthy before they will fill out a form. The funnel structure: headline-led hero with a social proof number (e.g., "Över 500 Implantat Genomförda"), three objection-handling sections (cost/payment options, treatment process, recovery time), before/after case study section (with patient consent and anonymisation), team credibility block (dentist credentials, experience), and a two-step form (Step 1: name + phone for callback; Step 2: treatment details on booking confirmation page). No hard booking calendar on the implantat funnel — the first step is a consultation callback, not a direct booking, because the treatment requires an assessment before scheduling.

The Allmän kontroll funnel is frictionless by design. A patient booking a check-up has already decided — they just need to find a clinic and book. The funnel: clean headline ("Boka Din Tandläkarkontroll Idag — Lediga Tider Nu"), embedded booking calendar immediately visible above the fold, three trust badges (GDPR, local clinic, experienced team), and that is it. No long copy. No case studies. The conversion action is the calendar booking itself, not a form fill to a callback.

Smart Call Lists and Power Dialer Configuration

The Smart Call List feature in GoHighLevel replaces the manual Google Sheets workflows that most dental receptions use to track who to call for recalls, confirmations, and follow-ups. The configuration creates five persistent Smart Lists that auto-populate based on contact field and tag criteria:

The Power Dialer is configured for the Recall — Ring Idag and Nya Leads — Ej Kontaktade lists. Reception can launch a dialing session from either list — GHL connects the call automatically to the next contact in the queue, logs the outcome (answered/no answer/booked/not interested) with a single click, and advances to the next contact. This replaces the workflow where a receptionist manually opens a spreadsheet row, dials the number on a separate phone, then manually records the outcome in a column. The time-per-call reduction in testing environments for this pattern is typically 40–60%.

Lead Scoring Rules

Lead scoring in GHL is implemented as a workflow-triggered property update — GHL does not have a native score object like HubSpot, so the lead_score custom number field carries the score, and workflows increment or decrement it based on defined trigger events.

Operations Dashboard and Weekly Marketing Report

The Phase 2 reporting layer is built in GHL's native dashboard builder. Two dashboards are created: the Daily Operations Dashboard (for reception and clinic managers — real-time operational view) and the Weekly Marketing Report (for clinic leadership — channel performance, funnel conversion, automation health).

Phase 3 — Data & Scale: The Infrastructure That Makes Expansion Effortless

Phase 3 is where a well-built GoHighLevel system becomes a competitive moat. Every dental group expanding from two clinics to five faces the same constraint: operational setup time per location. If each new clinic requires three weeks of CRM configuration, funnel rebuilding, and automation recreation, the technical debt compounds with every expansion. Phase 3 eliminates that constraint. A new AlphaClinic clinic should be fully operational — complete CRM, funnels, automations, calendar, and integrations — within one business day of the deployment decision being made.

Master Snapshot Creation and Deployment Process

The GHL snapshot is a full export of a sub-account's configuration: all pipelines, automation workflows, funnels, landing pages, forms, calendars, email templates, SMS templates, custom fields, tags, and Smart Lists — everything except the contact records themselves (patient data never moves between sub-accounts). The master snapshot is created from the MASTER sub-account (configured in Phase 1, built and tested in Phases 1–2), not from a live production clinic sub-account.

MASTER SNAPSHOT — INCLUDED COMPONENTS
──────────────────────────────────────────────────────────────────

PIPELINES (6):
  ✓ IMPLANTAT treatment pipeline (7 stages)
  ✓ ALLMÄN KONTROLL treatment pipeline (6 stages)  
  ✓ AKUTTANDVÅRD emergency pipeline (6 stages)
  ✓ LEAD MANAGEMENT operational pipeline (5 stages)
  ✓ RECALL OPERATIONS pipeline (6 stages)
  ✓ REPUTATION & REVIEWS pipeline (4 stages)

AUTOMATION WORKFLOWS (6 core + supporting):
  ✓ Speed-to-Lead (multi-branch: business hours / after hours)
  ✓ Missed Call Text-Back
  ✓ Booking Confirmation & Reminders (3 calendar variants)
  ✓ 6-Month Recall Sequence
  ✓ Google Review Collection
  ✓ Dead Lead Resurrection
  ✓ Emergency routing and escalation workflow
  ✓ Muntra sync trigger workflows (receives Make.com updates)
  ✓ Lead scoring update workflows (13 trigger events)
  ✓ GDPR consent quarantine workflow (fires if consent missing)
  ✓ Tag governance workflow (prevents duplicate tag creation)
  ✓ No-Show re-engagement workflow
  ✓ VIP identification workflow

FUNNELS & LANDING PAGES:
  ✓ Implantat funnel (2-step: hero + booking confirmation)
  ✓ Allmän kontroll funnel (direct booking embed)
  ✓ Thank you pages (post-form submission — both funnels)

CALENDARS (3 templates — placeholder names, renamed per clinic):
  ✓ Implantat Konsultation calendar
  ✓ Allmän Kontroll calendar
  ✓ Akuttandvård calendar (internal booking only)

EMAIL TEMPLATES (12 Swedish-language):
  ✓ Booking confirmation (3 variants by treatment type)
  ✓ 48h appointment reminder
  ✓ Post-visit thank you / review request
  ✓ Recall reminder (day 3)
  ✓ Recall final email (day 30)
  ✓ Dead lead resurrection (3 variants by angle)
  ✓ Implantat nurture sequence email

SMS TEMPLATES (15 Swedish-language):
  ✓ Speed-to-Lead immediate response
  ✓ Missed call text-back (known / unknown contact variants)
  ✓ Booking confirmation
  ✓ 24h reminder
  ✓ 1h reminder
  ✓ Recall day 0
  ✓ Recall day 7
  ✓ Recall day 14
  ✓ Dead lead resurrection (3 variants)
  ✓ Emergency routing confirmation
  ✓ Google review request

CUSTOM FIELDS (all 20):
  ✓ Clinical category (8 fields)
  ✓ Operational category (8 fields)
  ✓ Compliance category (4 fields)

TAGS (all 30 — with naming convention documentation):
  ✓ src_ prefix group (6 tags)
  ✓ trt_ prefix group (5 tags)
  ✓ status_ prefix group (8 tags)
  ✓ seq_ prefix group (7 tags)
  ✓ gdpr_ prefix group (2 tags)
  ✓ clinic_loc_ prefix group (2 tags — renamed per clinic on deployment)
  ✓ review_ prefix group (1 tag)

SMART LISTS (5):
  ✓ Recall — Ring Idag
  ✓ Nya Leads — Ej Kontaktade
  ✓ No-Show — Återboka
  ✓ Implantat — Ej Bekräftad
  ✓ Döda Leads — Uppföljning

DASHBOARDS (2):
  ✓ Daily Operations Dashboard
  ✓ Weekly Marketing Report

──────────────────────────────────────────────────────────────────

NEW CLINIC DEPLOYMENT CHECKLIST (target: under 1 business day)

  PRE-DEPLOYMENT (30 minutes):
  □ Create new sub-account in agency account
  □ Confirm EU data residency inherited
  □ Rename sub-account: AlphaClinic [Klinik Name]
  □ Execute snapshot deployment

  POST-SNAPSHOT (2–3 hours):
  □ Update clinic-specific variables: clinic name, phone, address,
     Google Maps link, Google Business Profile review link
  □ Connect clinic's Facebook Page and Instagram account
     to unified inbox
  □ Connect clinic's Meta Ads account + Google Ads account
  □ Configure GHL phone number for clinic (SMS + calls)
  □ Rename clinic_loc_ tags to match clinic name
  □ Set business hours for emergency workflow time-gating
  □ Add reception staff users with correct role permissions
  □ Configure Make.com scenarios with new sub-account API key
     and clinic's Muntra API credentials

  TESTING (2–3 hours):
  □ Submit test form on Implantat funnel → verify Speed-to-Lead fires
  □ Submit test form on Allmän kontroll funnel → verify booking
     calendar works and confirmation SMS sends
  □ Call clinic GHL number and hang up → verify Missed Call Text-Back fires
  □ Trigger test emergency contact → verify 15-minute escalation chain
  □ Run Make.com scenario manually → verify Muntra patient syncs to GHL
  □ Manually trigger Recall Sequence on test contact → verify all
     messages send in correct sequence with correct merge fields
  □ Book and cancel test appointment → verify cancellation workflow
  □ Confirm all dashboard widgets populate with test data

  SIGN-OFF:
  □ Clinic manager confirms dashboard access and correct data display
  □ Reception staff confirms Smart Lists visible and Power Dialer working
  □ Agency admin confirms EU data residency on new sub-account (screenshot)
  □ All test contacts deleted before live patient data import

Metabase BI Setup and the Full Attribution Model

Phase 3 adds the business intelligence layer that converts GHL's operational data — and Muntra's clinical data — into the revenue attribution model that justifies the ad spend, validates the automation performance, and enables data-driven expansion decisions. Metabase is the right BI tool for this configuration: open-source, SQL-queryable, embeddable, and capable of connecting to the PostgreSQL database that backs GHL's data export and the Muntra API data warehouse.

METABASE DATA ARCHITECTURE — ATTRIBUTION MODEL
──────────────────────────────────────────────────────────────────

DATA SOURCES CONNECTED TO METABASE:

Source 1: GHL Data (via GHL Reporting API or database export)
  Tables: contacts, contact_tags, pipeline_stages, 
          automation_events, form_submissions, appointments_ghl

Source 2: Muntra Clinical Data (via Make.com → data warehouse)
  Tables: patients, appointments_muntra, treatments, invoices
  → Make.com runs nightly export to PostgreSQL warehouse
  → Patient ID bridges GHL contact ↔ Muntra patient record

Source 3: Ad Platform Data (via API connectors)
  Google Ads: campaign_performance, ad_group_performance, conversions
  Meta Ads: campaign_insights, adset_insights, ad_insights
  → Connected via Metabase's native Google Ads connector
    and Meta Ads API integration

Source 4: UTM Attribution Data (from GHL contact records)
  → utm_source, utm_campaign, utm_content extracted from
    GHL contacts and joined to Muntra invoice data
    by muntra_patient_id bridge key

──────────────────────────────────────────────────────────────────

ATTRIBUTION MODEL — REVENUE WATERFALL

Step 1: Ad Spend → Lead
  → For each campaign: ad_spend / form_submissions
    = Cost Per Lead by channel and campaign

Step 2: Lead → Booking
  → form_submissions → appointment_booked (within 30 days)
    = Lead-to-Booking conversion rate by channel

Step 3: Booking → Attended
  → appointment_booked → appointment_attended
    = Show rate (identifies no-show problem by channel — 
      some ad channels may attract lower-quality leads)

Step 4: Attended → Treatment Revenue
  → appointment_attended → invoice_total (from Muntra)
    = Revenue per attended appointment
    = Average Treatment Value (ATV) by treatment type and channel

Step 5: Full CAC Calculation
  → Total ad spend / total new patients acquired (attended first appt)
    = Customer Acquisition Cost (CAC)
    Segmented by: channel, treatment type, clinic location

Step 6: LTV Calculation (Muntra data required)
  → treatment_revenue_total by patient × average retention period
    = Patient Lifetime Value (LTV)
    LTV / CAC ratio is the primary expansion investment metric

Five Metabase dashboards are built for Phase 3:

AI Chatbot Configuration for Social DM Inbox

The GHL-native AI chatbot is configured for the unified social DM inbox (Facebook + Instagram). The chatbot's role is precisely scoped: it handles initial inquiry responses and booking intent detection, and escalates to a human when the conversation requires clinical judgment, complaint handling, or price negotiation. It does not attempt to answer clinical questions — that is a compliance risk, not a UX feature.

AI CHATBOT — CONVERSATION FLOW DESIGN
──────────────────────────────────────────────────────────────────

TRIGGER: New inbound DM received (Facebook or Instagram)
         During non-business hours (after 17:00 CET, before 08:00 CET)
         OR during business hours if reception has 3+ open conversations

CHATBOT INITIAL RESPONSE (within 30 seconds):
  "Hej! Välkommen till AlphaClinic. Jag kan hjälpa dig att:
   1. Boka en tid för tandläkarkontroll
   2. Ställa en fråga om behandlingar
   3. Kontakta en av våra receptionister
   
   Vad kan vi hjälpa dig med?"

INTENT DETECTION (based on patient reply):

  IF booking intent detected (keywords: boka / tid / ledig / kontroll):
    → "Toppen! Klicka här för att see lediga tider och boka enkelt: 
       [Bokningslänk]"
    → Log interaction as booking_intent in GHL
    → Notify reception: "DM-konversation — bokningsintention"

  IF emergency intent detected (keywords: akut / smärta / ont / bruten):
    → "Det låter jobbigt! For akuta tandproblem ber vi dig att 
       ringar oss direkt på [kliniktelefon] — vi svarar omedelbart.
       Alternativt: [Akutbokningslänk]"
    → IMMEDIATELY tag contact: trt_emergency
    → Trigger emergency routing workflow
    → Escalate conversation to human reception immediately

  IF pricing question detected:
    → "Vi hjälper dig gärna med priser och behandlingsinformation. 
       En av våra receptionister svarar dig inom kort — 
       vanligtvis inom 15–30 minuter under öppettider."
    → Escalate to human — chatbot does NOT quote prices

  IF complaint or negative sentiment detected:
    → IMMEDIATE escalation to human
    → No automated response — human must handle this personally
    → Internal notification to clinic manager

  IF unclear intent:
    → "Kan du berätta lite mer om vad du behöver hjälp med? 
       Eller ring oss direkt på [kliniktelefon]."

BUSINESS HOURS HANDOFF:
  → All conversations with booking_intent or escalation flag
    are assigned to the first available reception user on login
  → Chatbot appends conversation summary to GHL contact notes
    before handing off: intent, keywords detected, links sent

VIP Patient Identification and No-Show Re-Engagement Workflows

These two Phase 3 workflows operate on existing patient data — they are not lead generation workflows. They are retention and relationship management workflows that run continuously against the patient database as Muntra data flows in.

VIP Patient Identification runs weekly against all active patient records and applies a multi-criteria scoring model. A patient meets VIP threshold if they meet any two of: lifetime treatment revenue ≥ SEK 15,000 (configurable), attended 3+ appointments in the last 18 months, referred 1+ new patients, or left a 5-star Google review. VIP patients receive a distinct communication approach: booking priority (reception manually calls to offer first access to calendar openings), personalised recall messages from their named treating dentist, and eventual VIP-tier loyalty communications (configured in Phase 3 with client approval on content and compliance review).

No-Show Re-Engagement fires when no_show_count is incremented to 1 or higher by the Muntra sync. The workflow is calibrated differently for first-time no-shows (empathetic, rebooking-focused) versus repeat no-shows (direct, confirmation-required before future bookings are released).

NO-SHOW RE-ENGAGEMENT WORKFLOW
──────────────────────────────────────────────────────────────────

TRIGGER: no_show_count incremented by Muntra sync

IF no_show_count = 1 (first no-show):
  
  T+2 HOURS: SMS (empathetic):
    "Hej [Förnamn], vi märkte att du inte kunde komma till din tid idag. 
     Hoppas allt är okej! Vill du boka om? [Bokningslänk]"
  
  T+24 HOURS (if no rebooking): Email:
    "Vi förstår att livet ibland ställer till det. Din tid hos oss 
     väntar när du är redo — boka enkelt online eller ring oss."
  
  T+7 DAYS (if still no rebooking):
    → Add to Smart List: No-Show — Återboka (reception personal call)

IF no_show_count = 2 (repeat no-show):
  
  T+2 HOURS: SMS (direct):
    "Hej [Förnamn], vi märkte att du missade din tid hos oss igen. 
     Vi håller gärna din nästa tid — men behöver en bekräftelse från 
     dig 48 timmar i förväg. Boka och bekräfta här: [Bokningslänk]"
  
  INTERNAL PROCESS UPDATE:
  → Tag: status_no_show (if not already present)
  → Reception note added: "2x no-show — require 48h confirmation 
     before next booking is confirmed"
  → No automated booking allowed for this contact until
    they confirm via SMS/phone call with reception

IF no_show_count ≥ 3:
  → Escalate to clinic manager for individual patient review
  → No automated outreach — human decision required

Monthly Audit Checklist and Handover Documentation

The final deliverable of Phase 3 — and the one most commonly omitted in GHL implementations — is the documentation and audit infrastructure that allows the client to maintain the system without perpetual agency dependency. The monthly audit checklist is not a template from the internet. It is built specifically for this system, referencing the exact workflows, pipelines, and integrations configured during the three phases.

The full handover documentation package — delivered at Phase 3 completion — includes: a clinic user training guide (Swedish language, reception-level — no technical jargon), a system architecture map (visual — all integrations, workflows, and data flows on one page), the Make.com scenario documentation (what each scenario does, what to check if it breaks), the GHL workflow index (all 13 workflows with trigger logic and exit conditions), the Metabase dashboard guide (how to read each metric, what actions each metric should trigger), and the monthly audit checklist (this section, formatted as a standalone PDF for clinic manager use).

What Makes This Build Different from a Standard GHL Setup

The average GoHighLevel implementation for a service business takes three to five days of configuration work and produces a system that looks complete on delivery and starts showing gaps at the six-week mark. The automation fires but the messages are generic English in a Swedish-language market. The pipelines are configured but nobody trained reception on how to use the Smart Lists. The Muntra sync was never tested against real patient data. The master snapshot was never created because the client didn't know to ask for it.

What differentiates this build is the constraint structure. Every architectural decision in Phase 1 was made with Phase 3 explicitly in mind. The naming conventions exist so that the master snapshot deploys cleanly. The custom field library was built before any automation, not alongside it, so that field reference errors don't appear in production. The GDPR configuration was the first thing documented, in writing, before patient data was touched — because the legal risk of getting that wrong in Sweden is not theoretical.

And the 15-minute emergency response protocol is tested with a live call before the system goes live — not assumed to work because the workflow diagram says it should.

"The difference between a GHL setup that holds together under real clinical volume and one that starts degrading by month three is not the number of automations. It is the precision of the field architecture, the discipline of the naming conventions, and the rigor of the testing protocol. You cannot shortcut any of those three things." Arsalan Faysal — Revenue Systems Architect

If you are building a multi-location GHL system for a healthcare client — or any regulated industry client — the sequence of work in this post is the sequence that holds together under audit. Build the compliance layer first. Build the architecture to the master snapshot from day one. Test every workflow that touches a patient before it goes live. And document everything that any future team member needs to maintain without you.

The 63 steps are not a checklist. They are a dependency chain. Each one is in the order it is in because skipping or reordering it breaks something downstream. Follow the chain, test the links, and deliver a system that still works 18 months after you hand it over.