CRM or CDP for a hospital group: which one you actually need
CRM or CDP is really a question about which failure hurts more: the doing or the seeing. A CRM changes what happens to an enquiry today. A data platform assembles one view of a person across units and channels. Most Indian hospital groups have a workflow and ownership problem, so I would fix the CRM first, build a small single view in a warehouse, and revisit the platform later.
Every year or so, someone in a hospital group circulates a note saying the CRM is not working and what the organisation really needs is a customer data platform. Sometimes that note is right. More often it describes a problem the CRM was never set up to solve, and buying a second system to sit on top of an unused first one makes things worse rather than better.
CRM or CDP is how the question reaches the room, usually in a budget cycle, usually with a slide behind it. It is not quite the right question, because the two do different work and a group of any size will eventually want both capabilities in some form. The useful question is which capability deserves money and management attention first, given what is actually broken today.
I have sat on both sides of this. I have watched groups buy a data platform while their contact centre still worked out of a spreadsheet, and I have watched groups patch a CRM for years because nobody would admit that identity, not workflow, had become the binding problem. Both mistakes are avoidable with a couple of honest questions.
What each of these systems is actually for
A CRM in a hospital is a system of action. It holds a record for each person who contacted you, assigns that record to someone, queues the next task, records the call or message, and tracks whether the enquiry turned into an appointment and whether the appointment was honoured. Its value is that work happens inside it and leaves a trace. If your agents are not working in it every hour of every shift, you do not have a CRM, you have a database with a login screen. I have written separately about what a hospital CRM is actually for, and the short version is that it is a contact centre tool before it is a marketing tool.
A customer data platform is a system of assembly. It pulls records from many sources, decides which records belong to the same human being, builds a single profile, and then makes segments of those profiles available to whatever sends messages or reports. It does not run workflow. It does not have queues or agents. Its value is that it answers a question no single source can answer: who is this person across everything we know about them, and what should we be allowed to do next.
Put crudely, a CRM knows what your team did and a data platform knows who your patients are. Different failures, different fixes.
CRM or CDP: the question underneath the question
When a hospital group tells me the CRM is failing, the complaint usually resolves into one of two very different statements.
The first is about work. Enquiries arrive and nobody owns them. The night shift does not pick up where the day shift stopped. A patient who called about a knee gets three calls about health checks and none about the knee. The unit thinks the central team is chasing the lead, the central team thinks the unit is. Nobody can say how many enquiries came in yesterday, let alone what happened to them. That is a workflow and accountability failure, and no amount of unified profiles will repair it.
The second is about identity. The same woman is in your systems as a registration at one unit, a web form at another, a health check booking, a WhatsApp conversation and a campaign click, and none of those five records know about each other. Marketing sends her an offer for a scan she had last month. The retention report double counts her. The group cannot tell whether its repeat rate is good because it cannot see repeats. That is an identity and data failure, and a better CRM workflow will not repair it either.
So the honest version of CRM or CDP is: is our pain in the doing, or in the seeing? Most Indian hospital groups I have worked with have far more pain in the doing than they are willing to say out loud, because it implicates people rather than software.
Where a hospital group’s data actually breaks
Before choosing anything, spend a fortnight looking at where your data comes apart. It is rarely where the slide says.
The registration system usually runs per unit, sometimes as separate instances with separate patient numbering, so the same person acquires a different identity in each hospital they visit. Phone numbers, which everyone treats as the identity key, are entered with country codes in some places and without in others, shared between family members, and changed without anyone updating the old record. Walk-in patients are often captured thinly. Health check and diagnostics run on their own flow. The international desk keeps its own tracker because the main system never fitted its process. Campaign platforms hold click and form data that never reaches the clinical side at all.
None of this is unusual and none of it is anyone’s fault in particular. It is what happens when systems are bought one problem at a time over a decade. But it means the work of making a single view is mostly cleaning, matching and governance work, not platform work. I have argued before that this is the data work nobody budgets for, and it is the part that no purchase removes. A data platform can automate the matching rules. It cannot decide them for you, and it cannot fix a field that was never captured.
The case for fixing the CRM first
I put the CRM first in most groups, and the reason is simple: it is the only one of the two that changes what happens to a patient today. A better queue, a clear owner, a first response inside minutes rather than hours, a follow-up that actually goes out, an appointment that gets confirmed. Those show up in the OPD count this quarter. A unified profile shows up in a report.
The signs that CRM is your real gap are easy to spot. Agents keep a parallel spreadsheet. There is no single number for enquiries received. Nobody can name the owner of an enquiry between shifts. Conversion is discussed as a feeling. Doctors complain that patients who called were never called back, and you cannot prove otherwise. Unit heads and the central team disagree about the same lead.
If that is your situation, the fix is process before purchase. Decide who owns an enquiry at each hour of the day. Decide what a qualified enquiry means. Decide what happens when a patient replies on WhatsApp at midnight. Then configure the CRM you already have around those decisions, and only then look at whether the tool itself is the constraint. The readiness check I run before any vendor demo exists precisely to stop a process problem being sold a software answer, and the hospital CRM readiness checklist on this site walks the same ground.
The case for a customer data platform
There is a real case, and I have seen groups reach it. It arrives when the operational side is genuinely working and the growth question has moved from acquisition to the whole relationship.
The conditions look like this. You run several units and at least one diagnostics or health check business, so the same household touches you through more than one door. Repeat and referral revenue matters enough that someone senior asks about it monthly. You are spending real money on channels and cannot tell which spend reaches people who are already your patients. You want to suppress messages to people who should not receive them, which is as much a decency question as a targeting one. You have retention programmes, chronic care follow-up or health check renewals that depend on knowing the last interaction rather than the last campaign.
If most of those are true, the missing capability is assembly, and the usual workarounds have run out. Once a group reaches this point, the cost of not having a single view shows up as wasted spend, annoyed patients and reports the board does not trust. That is worth solving properly.
The middle path most groups can actually afford
Here is the part the vendor conversation tends to skip. The capability a data platform provides can often be assembled from pieces a hospital group already owns or can buy far more cheaply: a data warehouse, a set of written identity rules, a scheduled job that matches and merges records, and the CRM as the place where the result is used.
It is less elegant, it needs an analyst and an engineer who will stay, and it will not give you a segment builder a marketing executive can use unaided. But it forces the group to make the identity decisions explicitly, which is the hard part anyway, and it produces something the team understands rather than something they trust blindly. The unified view many groups need is narrower than a full platform assumes.
The version I would avoid is the one where a platform is bought to substitute for that thinking. The matching rules still have to be decided by someone who knows that a shared family phone number is common, that a name can be transliterated three ways, and that two registrations a year apart at two units may or may not be the same person. Software will apply your rules faithfully. It will not tell you they were wrong.
Consent, purpose and the DPDP question
Assembling profiles across systems is exactly the activity Indian data protection rules care about most, so this cannot be an afterthought bolted on at the end of the project. Consent in a hospital is collected in many places for many purposes, and a treatment consent is not a marketing consent. When you merge five records into one profile, you also have to merge, or rather reconcile, five consent states, and the safe rule is that the narrowest purpose wins.
In practice that means the profile has to carry consent and purpose as first class fields, not as a flag someone remembers to check before a campaign. It means a documented retention period. It means the ability to honour a withdrawal across every system, which is a good test of whether your single view is real. I have set out the operational side of this in what consent under DPDP changes for hospital marketing. The point for this decision is that a data platform raises the stakes of getting consent architecture wrong, because it makes the data easier to act on at scale. If your consent capture is currently weak, that is an argument for fixing consent before buying assembly, not an argument for buying assembly to fix consent.
How I would choose
If I were handed this decision in an Indian hospital group tomorrow, I would ask three questions and let the answers settle it.
First: can we state, today, how many enquiries we received yesterday and who owns each one? If the answer is no, the money goes to the CRM and to the process around it, and the data platform conversation is postponed by a year. This is the situation in most groups, and the discipline of saying no here is worth more than any feature comparison.
Second: if the answer is yes, do we have more than one business touching the same household, and does anyone senior actually act on repeat and retention numbers? If nobody acts on them, a single view will be admired and ignored. Build the habit of using the data you have before buying more of it.
Third: if both are yes, can we describe our identity rules in a page of plain English, and can our IT team run a matching job on a warehouse? If they can, start there and see how far it gets you. If they cannot, and the volume across units is genuinely large, that is when buying assembly earns its keep.
My plain opinion: for perhaps nine out of ten Indian hospital groups asking this question this year, the answer is CRM first, warehouse second, platform later or never. The exception is the group that has already done the unglamorous work and is being held back by matching at scale. That group is rarer than the market suggests.
What I would do in the next ninety days
Start by counting. Take one month of enquiries across every door you have, including the ones nobody reports, and write down how many, from where, owned by whom, and what happened. Do it by hand if you must. The exercise usually ends the debate, because the size of the workflow gap becomes obvious.
Next, write the identity rules. One page. What makes two records the same person, what makes them different, what you do when you cannot tell. Have the contact centre lead, a unit registration head and someone from IT sign it. This page is the most valuable artefact in the whole project and it costs nothing but argument.
Then pick the smallest useful single view and build it once, in whatever you already have. One specialty, or the health check business, or international patients. Measure something with it that the leadership already argues about, which is usually repeat rate or wasted spend, and be careful to promise only what the data can support. My views on that restraint are in what attribution in healthcare can and cannot tell you.
Finally, put the platform question back on the agenda at the end of the quarter, with the counting, the rules and the small view in hand. You will find the decision has mostly made itself, and you will be buying to extend something that works instead of buying to rescue something that does not.
Questions people ask
It is the choice between investing in a system of action and a system of assembly. A CRM holds enquiries, assigns owners, queues tasks and records what the team did. A customer data platform pulls records from many sources, decides which belong to the same person and makes that single profile available for messaging and reporting. The decision is about which capability your group is missing most.
Some tools claim to, and at a small scale that can hold. In a multi unit group the two jobs pull in different directions: workflow tools are built around a queue and an agent, assembly tools are built around identity and history. What works in practice is a CRM as the place work happens, fed by a data layer that decides identity. The labels on the boxes matter less than that division.
Ask whether anyone can tell you how many enquiries arrived yesterday and who owns each one. If nobody can, the gap is workflow and the answer is the CRM and the process around it. If that is already solid and the arguments are instead about repeat patients, wasted spend or reports nobody trusts, the gap is assembly and a single view becomes worth funding.
Watch for a purchase being used to avoid a management problem. A platform bought while the contact centre still works out of spreadsheets will not be adopted, and the licence renews anyway. Ask what will change for a patient in the first quarter, who owns the change, and what the group will stop doing. Ask also about the internal staffing the project needs, because that cost usually lands later and unbudgeted.
No, and this is the most common misunderstanding. A platform applies matching rules quickly and consistently, but the rules have to be written by people who know how your records behave, including shared family phone numbers, transliterated names and separate patient numbering across units. It also cannot recover a field that was never captured. Cleaning and governance remain the largest part of the work either way.
Access to the registration systems at each unit, an agreed way to export without disturbing clinical operations, somewhere to hold the assembled data, and the ability to run a matching job on a schedule. They also need a clear owner for identity rules, because those decisions cannot sit with an engineer alone. If integration with the registration system is not solved, neither option delivers much.
Merging records means reconciling consent states, and a treatment consent is not a marketing consent. Consent and purpose should sit on the profile as proper fields, with a documented retention period and the ability to honour a withdrawal everywhere. Assembling data makes it easier to act on at scale, which raises the stakes if consent capture is weak. Fix capture before you build assembly.
Mainly the ability to stop wasting messages and money on people who are already patients or who should not be contacted at all. Suppression, sensible sequencing and honest repeat numbers come from assembly rather than from campaign tools. The gain is real, but it only appears if someone senior acts on those numbers every month. Otherwise the view is admired once and then ignored.
Often yes. A warehouse, written identity rules, a scheduled matching job and the CRM as the place the result gets used will cover what many groups need. It is less polished and depends on keeping an analyst and an engineer. The advantage is that the group makes its identity decisions explicitly rather than trusting a configuration nobody in the building can explain.
CRM work tied to process changes can show something within a quarter, because a clearer owner and a faster first response affect appointments almost immediately. Assembly takes longer, since the time goes into extracts, matching and consent reconciliation before anything is visible. Expect the first useful single view to arrive after months of work rather than weeks, and plan the narrative accordingly.
Ask them to run your awkward cases, not their clean ones. Two registrations at different units a year apart. A shared household phone number. A patient who withdraws consent. A night shift handover. Ask what happens when the registration system is unavailable. The product that handles the ugly cases calmly is the one worth shortlisting, whatever the dashboards look like.
A fortnight of honest work by a small group. Count one month of enquiries across every door including the ones nobody reports, look at how records break across units and channels, and try to write the identity rules on a single page. Most of the effort is getting people in a room and agreeing what is true, not analysis. The result usually settles the argument.
Buying assembly to avoid a conversation about accountability. The unified profile is a pleasant project because it implicates systems rather than people, while fixing enquiry ownership implicates managers. Groups that take the easier route end up with a second underused system and the original leakage intact. Start where the patient feels the failure, then extend into the data work once the basics hold.
