How EKSENAI Builds Patient Intake Systems for Turkish Clinics

Home AI & Automation How EKSENAI Builds Patient Intake Systems for Turkish Clinics

The first thing I do when a clinic contacts EKSENAI is not propose a solution. It is ask to see their WhatsApp history from the last 30 days. Every clinic that has agreed to that request has shown me the same thing: between 40 and 65 percent of their paid leads received either a delayed response, a single follow-up attempt, or no response at all. The system I build is designed specifically against that failure pattern.

Last Updated: 20260410T0

◆ AI SUMMARY
9 min read

EKSENAI builds patient intake systems for Turkish medical tourism clinics using a four-phase process: pipeline audit, architecture design, build and integration, and coordinator enablement. The stack: Evolution API, n8n, Chatwoot, Supabase, and OpenAI, is configured specifically for each clinic’s procedure mix, language markets, and coordinator structure. The result is a TFCR under 4 minutes, 95%+ CRM population rate, and a lead-to-consultation conversion rate that typically doubles within 60 days of go-live.

I’ve built intake systems for clinics in Istanbul across hair transplant, dental, and cosmetic surgery. EKSENAI’s process for building these systems has been refined across enough real deployments to have a specific methodology, not a generic software package, but a repeatable architecture customized to each clinic’s operational reality. What follows is exactly what that process looks like, from initial audit to a system running in production.

Phase Duration Deliverable Key Metric Established
Pipeline Audit 3–5 days Revenue Leakage report + TFCR baseline Current conversion rate, lead loss rate
Architecture Design 3–5 days System spec + coordinator workflow map Lead routing logic, CRM field map
Build & Integration 7–10 days Live system on staging All automations tested end-to-end
Coordinator Enablement 3–5 days Trained team + documented SOPs Chatwoot proficiency, escalation protocol
Go-Live + 30-Day Review Ongoing Live production system TFCR, conversion delta, coordinator metrics

What Does the Pipeline Audit Actually Reveal?

Every EKSENAI engagement starts with a pipeline audit before a single line of automation is discussed. This is non-negotiable because the system architecture depends entirely on where the clinic’s specific failure points are, and no two clinics fail in exactly the same way, even though the patterns are consistent.

The audit runs across three dimensions. First, I measure lead entry: how many leads are arriving per day, through which channels, and what the distribution is by procedure type and source country. For most Istanbul clinics, 60 to 75 percent of leads arrive through WhatsApp, with the remainder split between Instagram DM, website form, and referral. The WhatsApp concentration is both an asset and a vulnerability.

Second, I measure Lead Latency, the time between a patient’s inquiry and the first substantive response. This is different from TFCR because it includes automated responses if the clinic already has any. What I am measuring is the gap from the patient’s perspective: how long before they received something that addressed their question. In my experience with Istanbul clinics, this number is rarely below two hours and often exceeds six hours for inquiries that arrive outside business hours.

Third, I map the Coordinator Black Box: what data exists in the CRM versus what exists only in individual coordinators’ personal WhatsApp accounts. In most clinics I audit, management can account for 30 to 50 percent of the leads they paid to acquire. The rest are invisible, managed through personal messaging apps, stored in spreadsheets that coordinators own, or simply lost.

The audit output is a Revenue Leakage report that quantifies, in euro terms, what the clinic’s current failure pattern is costing them per month. This creates the basis for the architecture decision.

How Does EKSENAI Design the System Architecture?

1. What Determines the Technical Stack for Each Clinic?

The core stack: Evolution API for WhatsApp Business API access, n8n for workflow orchestration, Chatwoot for unified inbox and CRM, and Supabase for structured data storage, is consistent across all EKSENAI deployments. What varies is the configuration: the number of Evolution API instances, the language distribution of AI response templates, the CRM field structure in Supabase, and the coordinator assignment logic in Chatwoot.

A hair transplant clinic receiving 60 percent UK leads and 30 percent Gulf leads needs English and Arabic response templates as a minimum, with Turkish for occasional domestic inquiries. A dental clinic with a French market focus needs French, English, and potentially German. The architecture design phase maps this explicitly before any workflow is built.

2. How Is the n8n Workflow Structured?

The primary n8n workflow is triggered by a webhook from Evolution API when a new WhatsApp message arrives. The workflow branches based on whether the sending number is a new contact or an existing one in Supabase. New contacts enter the pre-qualification flow. Existing contacts are routed to the appropriate conversation thread in Chatwoot and flagged for coordinator follow-up based on where they are in the pipeline.

The pre-qualification flow sends the message content to OpenAI with a clinic-specific prompt that extracts procedure intent, source country, budget signals, and urgency indicators. The AI response populates a structured JSON object that n8n writes to Supabase, creating or updating the patient record, and uses to generate a personalized first-response message sent back through Evolution API. The full cycle, from incoming message to outgoing response and CRM update, completes in under 90 seconds.

3. How Does Chatwoot Fit Into the Coordinator Workflow?

Chatwoot functions as the coordinator’s primary working interface, the single place they manage all patient conversations, see CRM data, and action follow-ups. EKSENAI configures Chatwoot with custom labels that reflect the clinic’s specific pipeline stages: New Inquiry, Pre-Qualified, Consultation Booked, Pre-Op Confirmed, Post-Arrival, and Review Requested. Conversations move through these labels automatically as pipeline events are recorded in Supabase.

Coordinators do not need to update labels manually in most cases. When a consultation is booked in the booking system and the event is written to Supabase, the n8n workflow updates the Chatwoot conversation label automatically. This is the operational heart of the Coordinator Black Box elimination: management can see every lead’s stage without asking coordinators to self-report, because the data writes are automated.

What Happens During Coordinator Enablement?

The build phase produces a working technical system. The enablement phase determines whether that system actually changes clinic performance. In my experience, this phase is where the most overlooked work happens, and where deployments that skip it fail within 30 days.

Coordinator enablement covers three areas. The first is Chatwoot proficiency: coordinators learn the interface, the conversation labeling system, the escalation paths for complex cases, and the priority logic that surfaces hot leads. This takes a two-to-three-hour session with hands-on practice using real lead scenarios.

The second area is protocol alignment: what does the coordinator do when the AI first-response has already qualified a lead? What is the script framework for a DHI consultation booking conversation? When does a conversation escalate to a medical consultant versus staying with the coordinator? These are not new policies, they are existing clinic protocols made explicit and aligned to the new system’s handoff points.

The third area is metric awareness: coordinators are shown their own TFCR dashboard from day one. They know their response time is visible. This is not punitive, it is the first time most coordinators have had objective feedback on their performance. In my experience, coordinators who previously had no visibility into their own metrics respond positively to having data. The ones who do not are identified within the first week.

What Is the Underlying Principle Behind How EKSENAI Builds?

EKSENAI does not sell software. It sells an operational outcome: a clinic intake pipeline that captures the leads the clinic has already paid to acquire, qualifies them without coordinator bottleneck, and gives management the visibility to manage a real sales operation.

The technical stack, n8n, Evolution API, Chatwoot, Supabase, is the infrastructure for that outcome. The system design is the architecture. But the thing that makes it work is the alignment between the automated layers and the human coordinators who operate inside them. A system that the coordinators work around is not an intake system. It is an expensive parallel process that generates friction without result.

Every EKSENAI deployment ends with a 30-day review. We measure TFCR delta, conversion rate change, and CRM population rate against the audit baseline. In every deployment I have run, the TFCR is under 4 minutes within two weeks of go-live. Conversion rate improvement takes the full 60 to 90 days to stabilize. Revenue Leakage, the metric that matters most to clinic owners, falls below 20 percent within the first month and continues declining as the follow-up sequences mature.


Frequently Asked Questions

What does EKSENAI’s pipeline audit actually look at and how long does it take?

The EKSENAI pipeline audit takes three to five days and covers three areas: lead entry and volume by channel, Lead Latency from inquiry to first substantive response, and the Coordinator Black Box assessment of what lead data exists in the CRM versus what exists only in personal coordinator accounts. The output is a Revenue Leakage report that quantifies what the clinic’s current failure pattern costs in monthly revenue terms. This report forms the basis of every system architecture decision. No EKSENAI engagement proceeds without it.

Can EKSENAI deploy this system for a clinic that already uses Zoho or Bitrix24?

Yes, with a caveat. If the clinic requires that Zoho or Bitrix24 remain the primary CRM for legacy data or accounting integration, EKSENAI can build a system where Supabase functions as the intake and pipeline layer and syncs relevant records to the existing CRM. In practice, however, most clinics that go through the audit process choose to migrate their active pipeline management to Chatwoot because it is purpose-built for WhatsApp-first coordinator workflows in a way that Zoho and Bitrix24 are not. The legacy CRM can remain for historical records and financial reporting without disrupting the new intake architecture.

How does EKSENAI handle WhatsApp number migration for clinics with existing patient relationships?

This is one of the most operationally sensitive parts of any deployment. A clinic with 3,000 existing WhatsApp contacts cannot simply switch to a new number. EKSENAI handles this through a phased migration: the existing number continues to receive messages through a WhatsApp Business app during the transition period, while the new Evolution API instance is warmed up on a separate number for all new leads. Over 30 to 60 days, existing patients are migrated to the new number through a directed transition message. This preserves existing relationships while ensuring new lead traffic enters the automated system from day one.

What ongoing support does EKSENAI provide after go-live?

EKSENAI provides a 30-day post-launch review as standard, which includes a detailed metric comparison against the pre-audit baseline. After that, clinics receive documentation and a basic maintenance protocol covering the most common operational tasks: Evolution API instance reconnection, n8n workflow updates for seasonal promotions, and Chatwoot configuration changes for new coordinators. For clinics that want ongoing system management, EKSENAI offers a monthly retainer that covers workflow updates, new automation builds as the clinic’s needs evolve, and monthly performance reviews.

What is TÜRSAB and does it affect how the intake system is configured?

TÜRSAB is Turkey’s Association of Tourist Guides and Travel Agencies, and under Turkish law, medical tourism facilitators, including clinics that actively market to international patients, are required to hold a TÜRSAB license for certain patient facilitation activities. This affects how a clinic can legally position certain communications with international patients. EKSENAI accounts for this in the compliance layer of the system design, ensuring that automated messages and lead capture flows align with both TÜRSAB requirements and WhatsApp Business API terms of service. JCI-accredited clinics have additional compliance documentation requirements that also factor into the CRM field structure EKSENAI configures.