Running a CRM readiness check before any vendor demo

A CRM readiness check tells a hospital whether it could use a CRM well before any vendor demo shapes the requirements. Map real enquiry journeys, sample data from the HIS and telephony, assess integrations with IT, name a business owner, settle consent under DPDP, and agree the few measures you need. Then script demos around your actual gaps.

A CRM vendor demo is a performance. The pipeline is clean, every enquiry has a source, every agent follows the script, the dashboards glow. Nobody in the room is lying. They are simply showing the product running on data and processes that look nothing like yours. The trouble starts after purchase, when the tool meets your real enquiries, your real contact centre and your real HIS.

That is why I run a CRM readiness check before any vendor gets a demo slot. It is an internal exercise, usually done in a few weeks, that answers a blunt question: if we had the perfect CRM tomorrow, could we actually use it? Most hospitals discover they cannot yet, and that the gaps are in process, data and ownership rather than software.

This explainer walks through how to run that check, area by area, and how to use the result to run better demos. The hospital CRM readiness checklist on this site follows the same areas if you want to score yourself as you go.

Why a CRM readiness check comes before the demo

Demos shape requirements more than requirements shape demos. Once a team has seen a slick product, the feature list starts to mirror what was shown, and the conversation drifts to dashboards and AI features. The questions that decide whether a CRM will work inside a hospital, such as who owns an enquiry at two in the morning or how a booking gets written into the HIS, rarely come up, because the vendor has no reason to raise them.

A readiness check reverses that order. You arrive at the demo knowing your own weak points, and you ask the vendor to show how the product behaves in exactly those conditions. The demo becomes a test rather than a presentation. It also protects the budget. A CRM bought before the organisation is ready tends to become an expensive lead inbox, used by a few agents and ignored by everyone else, and that failure is usually blamed on the vendor rather than the preparation.

If you have not yet agreed what the CRM is meant to do, start there. I have set out my view in what a hospital CRM is actually for. The readiness check assumes you have at least a working answer to that question.

Area one: the enquiry journeys you actually run

Begin by mapping, on paper, how enquiries arrive and what happens to them today. Not the process in the SOP document, the process on the floor. Sit with the contact centre, the OPD front desk, the health check desk, the international desk and whoever answers WhatsApp. Trace a handful of real enquiries from first contact to honoured appointment, or to the point where they were lost.

You are looking for the number of distinct journeys, the handoffs between teams, and the places where information is retyped or lost. Most hospitals find more journeys than they expected: OPD appointments, health checks, second opinions, admissions and estimates, corporate and TPA enquiries, international patients, home care, pharmacy. Each will need its own treatment in the CRM, and not all of them should be in scope for the first phase.

The output of this area is a short document listing the journeys, their owners and a first view of which ones the CRM must handle at launch. Without it, you cannot judge whether a vendor’s workflow design fits your reality, because you do not yet know your reality.

In a multi-unit group, repeat the tracing in at least two units. Journeys that look identical on the group SOP often differ sharply between a flagship hospital and a smaller unit in another city: different staffing, different hours, sometimes a different HIS instance. A CRM designed around the flagship alone will frustrate everyone else, and the smaller units are often where the enquiry leakage is worst.

Area two: data you have, data you think you have

A CRM runs on data from other systems. The readiness check asks, for each source, whether the data exists, where it lives, how clean it is and whether it can be accessed. The usual sources are the HIS for patient records, appointments and registrations; the telephony system for calls; web forms and chat; the WhatsApp business platform; marketing platforms for campaign data; and sometimes billing and pharmacy.

The recurring problems are predictable. Patient records are duplicated across units. Phone numbers are stored in different formats. Doctor and department names differ between the HIS and the website. Appointment data sits in a scheduling module with no clean export. Call recordings exist, but call outcomes are not recorded anywhere. None of this is unusual, and none of it is solved by buying software.

I would sample a small set of records from each source and check them by hand. It is tedious and revealing. The work of cleaning and connecting data is usually larger than the CRM configuration itself, which is the point I make in the data work nobody budgets for. Budget it now, before a vendor quote anchors everyone’s expectations.

Area three: integration with the HIS and telephony

A CRM that cannot see appointments and arrivals cannot tell you whether an enquiry became a patient. A CRM that is not connected to the phone system will depend on agents typing call notes, which they will not do consistently under pressure. These two integrations decide more about the success of a hospital CRM than any feature on the vendor’s slides.

For the HIS, find out what interfaces exist, who controls them, what they cost, how long the HIS vendor takes to deliver changes and whether appointment booking can be written back from outside. For telephony, check whether calls can be routed and logged against a patient record, whether call outcomes can be captured with one click, and whether the telephony vendor has worked with CRM platforms before.

Bring IT into this early. The IT head should own the integration assessment, with a named person who will stay through implementation. Many CRM projects stall at this stage because integrations were assumed in the business case and discovered to be difficult only after the contract was signed.

Do not forget the WhatsApp business platform and the website forms. Many hospitals already run WhatsApp through a separate provider, with its own templates, opt-outs and conversation history. Decide early whether that platform stays and connects to the CRM, or moves inside it. Either answer can work. Leaving the question open until implementation is what causes duplicated conversations and patients receiving messages from two systems.

Area four: people, ownership and the contact centre

Software does not own enquiries. People do. The readiness check asks who will own each journey in the CRM, who will manage the contact centre’s use of it day to day, and who will own the system itself: configuration, users, reports and change requests. In many hospitals, the answer to the last question is a vague mix of marketing and IT, which is a warning sign.

Look honestly at the contact centre. How many agents, what shifts, what training, what attrition? Are they measured on calls handled or on appointments booked? A CRM that introduces structured workflows will change their day, and adoption depends on supervisors who believe in it. If supervisors are overloaded and agents turn over quickly, plan for heavier training and simpler workflows.

Name a business owner for the CRM before any demo. This person should be senior enough to settle arguments between departments and close enough to operations to understand what agents face. Without that owner, the vendor will fill the vacuum, and you will end up managing their project instead of your own, the trap I describe in managing vendors without becoming their project manager.

Area five: consent, DPDP and governance

A CRM will hold personal and health-related data for large numbers of patients and prospective patients. The readiness check should confirm that the hospital knows what notice and consent it collects at each point of contact, where consent is recorded, how opt-outs are handled and who can see what. The DPDP Act makes this a board-level matter, not a technical detail.

Specific questions worth answering before a demo: can you record consent at the point of enquiry, including on calls and WhatsApp? Do you have an agreed retention policy for enquiry data that never became a patient? Which roles should see clinical information, and which should not? How will data be shared across units in a multi-unit group? Your compliance and legal teams should own the answers, but the growth team should draft the questions.

These answers become requirements. A vendor who cannot show role-based access, consent records, audit trails and deletion workflows on realistic scenarios is not ready for a hospital, however good the marketing automation looks.

Area six: the measures you want the CRM to produce

Decide, before the demo, which few numbers the CRM must make reliable. My shortlist starts with enquiry to honoured appointment by channel, specialty and unit; response time to enquiries by channel and hour; and the reasons enquiries are lost. The ratio I care about most is set out in enquiry to appointment: the number that matters.

Write down how each measure will be calculated and which data it needs. Then check the readiness areas again: can your journeys, data, integrations and people actually produce those numbers? If not, the gaps become part of the implementation plan, and some may be worth fixing before any CRM arrives.

This step also clarifies what you do not need. Many hospitals are sold sophisticated lead scoring and journey builders when their first problem is that nobody can say how many enquiries became patients last month. Start with the measures that matter and let features follow.

Turning the result into a better demo

At the end of the check you should have a short readiness summary: the journeys in scope, the state of the data, the integration position, the owner and team, the consent position and the measures required. Score each area plainly as ready, partly ready or not ready. Share it with leadership before you invite vendors. It often changes the timeline, and occasionally the decision to buy at all.

Then use the summary to script the demos. Give each vendor the same scenarios, drawn from your real journeys, and ask them to show the product handling them live.

• A duplicate patient enquiring through a web form and a phone call on the same day.
• A WhatsApp enquiry at night that must reach a named agent by morning with its history intact.
• An appointment booked in the CRM and written into the HIS, then marked as honoured on arrival.
• A patient withdrawing consent, and the CRM suppressing every future message across teams.
• A unit head viewing enquiry to honoured appointment for their unit only.

Vendors who show these on realistic data are worth a second meeting. Those who return to their standard presentation have told you something useful. For the broader decision about whether to buy, build or combine, see how I decide on healthtech vendors.

A fortnight before the first demo

If demos are already booked, you can still run a compressed version of the check. In the first week, trace real enquiries through two or three of your busiest journeys, sample data from the HIS and telephony, and ask IT for a written view of integration options. In the second week, name the business owner, confirm the consent position with compliance, agree the three measures you need, and write the demo scenarios.

Score yourself against the readiness checklist and be honest about the areas marked not ready. Share the scores with the vendors in advance and ask them to address those gaps directly in the demo. The good ones will welcome it.

Then, whatever you decide, keep the readiness summary. It becomes the first page of the implementation plan, and it is the document you will want to reread when the project hits its first difficult month.

Questions people ask