What a hospital CRM is actually for

Most hospital groups I know are on their second CRM. The first one was bought to “get a single view of the patient”, went live in three units, was used by the contact centre as a call log, and was quietly replaced four years later by a different product bought to get a single view of the patient.

The failure is almost never the software. It is that nobody in the room could answer a simpler question: what do we intend to do to a patient record that we cannot do today? Until that question has three or four specific answers with owners attached, you are buying a database with a dashboard on it, and a database that only records is a cost centre with a licence fee.

A CRM earns its keep when it causes an outbound action that would not otherwise have happened. That is the whole test. Everything else — the 360-degree view, the unified timeline, the segmentation builder — is infrastructure for that action or it is decoration.

A record system and a growth system are different things

Your HIS already holds the clinical record. Your billing system holds the financial one. The LIS holds the reports. None of these is a CRM and none of them should be asked to become one, because their job is accuracy at the moment of the transaction and a CRM’s job is usefulness in the weeks after it.

The distinction that matters operationally: a record system answers “what happened to this patient?” A growth system answers “what should happen to this patient next, who is going to make it happen, and did it work?” The second question requires things the first does not have — a consent state, a contactability state, a next-best-action, an owner, an outcome field, and a suppression list.

I have watched two groups spend a year integrating every system into a CRM and then use it for nothing, because the integration project consumed the budget and the goodwill that the campaign work needed. Integrate less, act sooner. A CRM holding three well-chosen data points that drives a daily call list beats one holding four hundred fields that drives nothing.

The four use cases that actually justify it

These are the ones I have seen pay back. Not the only ones, but the ones where the causal chain from record to revenue is short enough that a CFO can follow it.

Recall for chronic and follow-up care. The diabetic due for an HbA1c. The cardiac patient at ninety days post-procedure. The thyroid patient on annual review. These patients already trust you, already have a file, and in the absence of a prompt will simply not come — not because they chose a competitor, but because nothing reminded them. Recall is the single highest-yield CRM use case in Indian hospitals and the most neglected, because it generates no new logos and therefore nobody presents it.

Referral relationship management. Your referring GPs and diagnostic centres are a sales pipeline, and almost nobody manages them like one. Which doctor referred how many, to whom, with what conversion, and when did a regular referrer go quiet? That last signal — a referrer whose volume dropped for two months — is worth more than any lead source report, and it is invisible without a CRM that treats the referrer as an entity rather than a text field on an admission form.

Post-discharge. Partly clinical, partly commercial, and the place where the two are genuinely aligned. A structured contact at forty-eight hours and at two weeks reduces readmission arguments, surfaces complications early, produces the feedback you need for NABH documentation, and — incidentally — catches the patient who is about to go elsewhere for physiotherapy you also provide. Run it as a care programme with a marketing benefit, never the reverse. The moment the forty-eight-hour call starts with an offer, you have burned the channel.

Health-check renewal. The closest thing a hospital has to a subscription. Someone who did a master health check last November is the warmest possible prospect this November, and the renewal rate of an unmanaged base is embarrassing. This is also the safest place to learn the mechanics — low clinical risk, clear consent basis, measurable within a quarter.

Notice what is not on this list: acquisition. A CRM is a poor acquisition tool. It is an extraordinary retention and reactivation tool. Groups that buy one to generate new patients are disappointed, correctly.

The data ownership fight you will have

You will have it. Plan for it rather than discovering it in month five.

There are four claimants on a patient record and each has a real argument. Medical records and the clinical leadership hold custody and are accountable for confidentiality. IT holds the systems and, quite reasonably, does not want marketing writing to a production database. The unit believes — culturally, and often contractually where consultants are concerned — that the patient belongs to the hospital the patient walked into, not to the group. Marketing wants to segment and contact.

The settlement that has worked for me is narrow and written down: marketing gets read access to a defined set of non-clinical fields plus a derived clinical flag, never the diagnosis text. A cardiac patient appears as “cardiac follow-up due” and not as a condition. Outbound communication templates are approved by a clinician once, per programme, and then marketing may execute without a per-send approval. Any send touching an oncology, mental health, fertility or HIV cohort goes through a named clinician every time, no exceptions, and I would not negotiate that one down.

Write this as a one-page data use note, get the medical director and the CIO to sign it, and attach it to the CRM’s access configuration. It will save you nine arguments, and it is also the artefact your DPDP readiness work will ask for later.

Consent is not a checkbox you can retrofit

Under India’s data protection regime you need a defensible basis for the contact and a working mechanism for withdrawal, and “the patient gave us their number at registration” is not a consent framework for marketing communication. Care-related communication and promotional communication sit in different places, and the distinction is not cosmetic — it determines what you may send to a base you have already collected.

Three practical things. Capture consent separately for care communication and for promotional communication, at registration, in the patient’s language. Store the timestamp, the channel, the version of the wording and the capture point. Make withdrawal work in one step and honour it across every system within twenty-four hours, which means your CRM must be the suppression master and every other outbound tool must read from it.

The retrofit is painful and there is no clever way around it. You will end up with a large legacy base you can contact for care and a much smaller one you can contact for promotions, and you should tell the board that before you start rather than after they ask why reachable volumes fell.

The adoption problem is at the unit, not the centre

The centre buys the CRM. The unit has to use it. And the unit’s front office is staffed by people managing a queue of anxious humans, with a shift change, a doctor running late and a TPA query pending. Every field you ask them to fill is a tax on that queue.

What I have seen fail: mandatory fields at registration that nobody validates, so they get filled with 9999999999. Lead-source dropdowns with twenty-two options, of which “Others” absorbs most of the volume. A CRM interface the front office has to open in a second tab alongside the HIS. Training delivered once, by a vendor, to people who were on the floor that afternoon.

What has worked: make the CRM field count at registration as small as you can defend — name, number, consent state, locality, source category with five options. Put the CRM inside the HIS workflow rather than beside it, even if the integration is ugly, because a second login means no data. Pick one person per unit — usually a front-office supervisor, not a manager — and make CRM hygiene an explicit part of their appraisal with a weekly score that their unit head sees. And report the score by unit in the same review where footfall is discussed, because nothing changes unit behaviour like comparison to the unit down the road.

Do not expect enthusiasm. Expect compliance, measured weekly, for about two quarters, after which it becomes habit.

The reports to stop building

A CRM will happily generate fifty reports and the existence of the reports becomes a substitute for the work. I would keep four. Contactable base by cohort, because it tells you the size of the lever. Programme output — appointments created by each programme, not messages sent. Suppression and complaint rate, because that is your early warning that a programme is burning the base. And referrer activity change, which is the only one anyone outside marketing will ask to see twice.

Delete the rest, or at least stop presenting them. Every report you show in a review becomes a thing you are accountable for improving, and half of them cannot be improved by any action available to you.

What I would do differently

I sequenced a CRM programme around integration milestones and it cost me most of a year. The first visible output was a dashboard, which impressed the steering committee and changed nothing, and by the time we were ready to run an actual recall programme the organisation had decided the CRM was a reporting tool. That framing took another year to undo.

If I had it again I would run one recall programme in one unit on an exported spreadsheet and a shared calling list before the CRM was procured. Crude, manual, entirely unscalable — and it would have proved the mechanism, produced a number, and given the eventual CRM a job description written by people who had already done the work by hand.

If you are starting this next quarter

1. Write the three programmes first. Recall, health-check renewal, post-discharge. One page each: the cohort, the trigger, the message, who calls, what counts as success.
2. Run one of them manually in a single unit for six weeks. No procurement. Learn the real objection handling and the real contactability rate.
3. Settle the data use note with the medical director and the CIO while the manual pilot runs. Signed, one page, specific fields.
4. Fix consent capture at registration before you scale anything. This is the dependency that blocks everything downstream.
5. Then specify the CRM against the three programmes, not against a feature comparison. Your requirement document should read like a campaign calendar, not a checklist.
6. Integrate the minimum. Identity, visit history, the clinical flags your programmes need, billing status. Nothing else in phase one.
7. Appoint unit-level owners and publish a weekly hygiene score from day one of go-live, not after adoption disappoints you.
8. Measure one thing per programme — appointments generated that would not otherwise have existed — and put it in the monthly review next to media spend.

A CRM does not give you a single view of the patient. It gives you somewhere to stand when you decide to call them. If nobody is going to call, save the licence fee and buy a better contact centre instead.

Questions people ask