Patient coordinator and CRM: source-to-booking attribution
Source-to-appointment attribution in a clinic CRM without relying on the coordinator's memory: data model, coordinator workflow, stages, feedback loop.
By Roozbeh Nazari · CEO
In a clinic receiving international patients, the place where source-to-appointment attribution breaks is usually not the technology but the desk. We covered the setup of the WhatsApp Business Platform and how source information rides along with the conversation in the WhatsApp funnel article, and which contact counts as a real lead in the lead quality article. This article looks at the human layer in between: how the patient coordinator's workflow and the CRM's data model are set up so that source information is carried all the way to the appointment. The goal is for the answer to "where did this patient come from" to live in the record, not in the coordinator's memory.
Why attribution breaks at the coordinator's desk
There are four patterns that recur in the clinics we work with. First, asking the patient for the source: the answer to "where did you hear about us" is the last touch the patient remembers; a patient who came from a search engine and then followed the clinic on Instagram says "Instagram", and the search channel is erased from the record. Second, the language-based coordinator structure: Arabic-, Persian- and English-speaking coordinators work with separate phones, sometimes separate spreadsheets, and the same patient becomes two records. Third, free text: when the source field in the CRM is typed freely, the same channel appears in ten spellings and no report can be produced. Fourth, deposits and appointments recorded outside the CRM, in accounting or in the hospital information system; source information starts with the contact, appointment information ends in another system, and the two never merge.
These four problems come from the same root: a human fills in the source field. The fix is for automation to write the source and for the coordinator to enter only the stage and treatment information.
The CRM data model: which fields, who writes them
A clinic-specific CRM is not needed; what is needed is that every lead record contains the fields below and that it is decided who writes each of them.
- Fields written by automation: first-touch source, medium and campaign (from the parameters in the page URL), click identifiers (gclid, wbraid and gbraid for Google; fbclid for Meta), landing page, page language and visitor country, contact channel (form, WhatsApp, phone), contact time.
- Fields written by the coordinator: treatment of interest, stage and stage date, quote amount, travel date, responsible coordinator, the source the patient states themselves (in a separate field, never overwriting the automation field).
- Fields derived by the system: lead id, time between stages, number of repeat contacts.
The rule is simple but takes discipline to apply: fields written by automation cannot be edited by the coordinator. The source stated by the patient is kept to see inconsistency; it is not the source of the channel report. For conversations coming from WhatsApp the key is the phone number, for those coming from the form it is the e-mail; if the two channels belong to the same person the records are merged and the source of the first contact is preserved.
The coordinator workflow
Even with a correct data model, if the coordinator does not open the record while giving the first reply, the chain breaks again. The flow we apply has five steps. The first reply starts from the CRM, not from the conversation: the coordinator first finds the record or claims the one opened by automation, then writes the reply. For phone calls, language-specific pages get separate tracking numbers; the coordinator records which number the call came in on and does not ask the patient for the source. In handovers between coordinators the lead id travels; a patient moving from the Arabic coordinator to the English coordinator does not become a new record. Quotes and deposits go into the record the same day; a deposit recorded in the accounting system is linked to the CRM record through a daily reconciliation. In the weekly hygiene meeting, records whose source shows "unknown" and duplicate records are handled one by one.
The stage definition is the most often skipped part of this flow. The word "appointment" means a date being given in one clinic, a deposit being taken in another, the patient boarding the plane in a third. The definition has to be written once and embedded in the CRM's stage list; the order we recommend is contact, qualified contact, quote sent, deposit received, travel date confirmed, treatment performed and follow-up. Everyone understanding the same stage when the report says "appointment" is the precondition of any channel comparison. Allowing only the responsible coordinator to change a stage, and recording every change with a timestamp, ensures there is later a single answer to "when did this patient pay the deposit".
Feedback: returning the appointment to advertising and analytics systems
When source information lands in the CRM, half the job is done; the other half is returning deposit and treatment information to the advertising and analytics systems. Google Ads' offline conversion import documentation makes it possible to measure what happens in the offline world after an ad is clicked, and describes storing the click identifier together with the lead information and returning it when the conversion happens. The same document states that from 15 June 2026 offline conversion imports and enhanced conversions for leads uploads have been migrated to the Data Manager API and blocked in the Google Ads API; a clinic building the integration today should start directly with Data Manager. For records where the click identifier was not stored, enhanced conversions match on a hashed value of the e-mail address or phone number the patient provided.
On the GA4 side, the Data Import feature joins data from external sources with analytics data; the importable types include events and user data, which means the deposit stage can be seen as an event in GA4. The User-ID feature ties the clinic's own identifier to behaviour across sessions and devices; passing the CRM lead id to GA4 as the User-ID gathers the path from first visit to deposit under a single user. This feedback layer carries consent, hashing and personal data obligations; how to build it in a cookieless world was covered in detail in the first-party data plan article.
Reporting: measure the chain, not the coordinator
Once this setup is in place, the report that can be produced is contacts, qualified contacts, deposits and treatments by channel, with the time between stages, broken down by language version and country. We watch three indicators: the share of records with an unknown source, the channel that reaches deposit fastest, and stage-progression time per coordinator. The last indicator is not used to rank coordinators but to see in which language and channel work is piling up. Setting up this report is part of our analytics and data work; in the projects we run for clinics, advertising budget decisions come out of this table, not out of the form count.
Conclusion
Source-to-appointment attribution is not a software feature but a workflow decision: automation writes the source, the coordinator writes the stage, the stage definition is single, and deposit information returns to the advertising and analytics systems. These four rules work regardless of the CRM brand. To see which link in the chain is broken, it is enough to look today at the share of records in the CRM whose source is "unknown"; until that share drops, no channel comparison is reliable.