Work: Healthcare Marketing, AI and Digital Transformation Case Studies

A new multi-specialty hospital in a city where the group name was known but the building was not. Senior consultants had not all signed, the opening date was likely to move, and digital had one line in the capex plan rather than a plan of its own.

I agreed the digital scope in writing with the project director early: the unit’s identity in search and maps, its pages on the group website, doctor content, the enquiry to appointment path through the contact centre and CRM, and launch communication. Signage, the opening event and equipment commissioning stayed with the people who own them. Then I sequenced the work: name, listing and number first; the unit and its lead specialties as first-class pages on the group site, not a new microsite; most of the spend held for the opening fortnight.

• I chose two or three lead specialties from catchment gaps, doctor strength and capacity, instead of marketing everything at once.
• No dates in creative and no countdowns until the date had been confirmed twice, because opening dates slip and every asset had to survive a change without rework.
• Pre-launch effort went into referral visits led by a clinician, community groundwork and a list of real people we could call on opening day, not a “coming soon” campaign. The trade-off: less visible activity for leadership in the months before opening.
• I built the launch-month contact centre from a question bank of real pre-launch enquiries, with honest “not yet” answers for services that were not live, a short phone menu with emergency first, and every unanswered call turned into a CRM callback task with an owner.
• Copy said which doors were open: OPD first, then day care, then beds, so nobody arrived at night to a locked emergency.

The hospital existed as a verified place in search and maps before it opened, and the contact centre could answer the questions callers actually asked. Early numbers were read against a written readiness position (services live, consultants present, payers active) instead of against the business plan, and every lost enquiry got a reason code that went to a weekly working meeting with operations.

I would not fund a pre-launch awareness campaign at all; I have paid for one and it bought nothing I could trace. I would also attach the readiness position to every report from the first day. I have made week-two decisions on curiosity-driven numbers and regretted them.

• New hospital marketing plan: 12 months to day 90
• Pre-launch demand when you have no doctors to name yet
• The launch-month contact centre: scripts, routing and cover
• The first ninety days after opening
• Tool: hospital launch budget planner

Enquiries arrived by phone, website forms, WhatsApp, aggregators and walk-ins, and each landed somewhere different. Units defined an enquiry differently, the contact centre logged calls in its own tool, and nobody could link a lead to a treated patient. Each unit believed a patient who touched two hospitals was theirs.

I treated the CRM as a definitions project before a software project. We agreed the patient data model and journey stages centrally, with unit heads and the contact centre in the room; evaluated vendors by asking them to configure our stages and consent record on our data rather than watching a demo; proved it in one busy pilot unit with every channel connected; then rolled out unit by unit in order of readiness, not hierarchy.

• Lead ownership was written down before go-live: ownership means accountability for the next action with a clock running, not which unit gets the revenue. That separation is what stopped the turf war. Cross-unit cases each got a rule.
• Routing became hub and spoke, and slot visibility across units was treated as a routing input, so a central agent could offer a sister hospital instead of losing the patient to a competitor.
• One source taxonomy for the whole group, chosen from a fixed list, and credit given at the treated patient by linking the CRM record to the hospital information system through the registration ID.
• Units could localise doctor availability, languages and escalation rules, never the definitions. The trade-off: a slower start and more meetings with unit heads before anything went live.
• Voice automation was framed around abandoned calls, repeat calls and misrouting, not headcount, so the team that had to make it work was not demoralised by the business case.

The test for the pilot was simple: the unit head used the CRM report in the weekly review instead of their own register. Unanswered calls became callback tasks with an owner and a time limit. The argument between central marketing and units moved from whose number was right to which leak to fix first.

For most of a year I held every unit to the same cost-per-appointment target. New units looked worse and were starved; mature units looked good and were overfunded, so we paid to buy back our own demand. I would set targets by unit maturity and service line from the start.

• Hospital CRM implementation: a phased rollout plan
• Multi-hospital CRM: lead ownership, routing and attribution
• Voice bots in the contact centre: what actually moved cost
• The multi-unit patient acquisition funnel, honestly mapped
• Tool: hospital CRM readiness checklist

Patients had started asking AI assistants which hospital to go to for a procedure in their city, and reading one composed answer instead of a list of links. The group’s units, doctors and specialties were described inconsistently across its own site, map listings and aggregators, which gives a cautious answer engine every reason to cite someone else, or to get our facts wrong.

I started with an audit, not a tool purchase: a frozen set of patient-style questions built from contact-centre call reasons, WhatsApp logs and search terms, asked in clean, unpersonalised sessions across several assistants, including in regional languages. Every wrong or missing fact was traced to its likely source. Then the work ran in a fixed order: fix the entity problem, make the facts machine-readable, build corroboration on trusted third-party sites, rewrite key pages so the first lines answer the question, and remove what was actively hurting.

• I treated GEO as hygiene with named owners across digital, the units and the doctors’ office, not as a campaign.
• Stale listings and old doctor profiles were fixed before any new content was written, because that is where most wrong answers came from.
• Consistency beat cleverness: the same names, addresses, specialties and doctor affiliations everywhere a machine might read them, declared in structured data.
• Questions stayed frozen between cycles, so change could be seen; the temptation to tweak them each month was the main threat to the method.
• The trade-off: most of this work is invisible to leadership and attribution is weak, so I reported presence and accuracy of answers over time rather than claiming traffic it could not prove.

Answers about the group became more accurate and more consistent across assistants, and the team had a repeatable check instead of screenshots from someone’s phone. GEO moved from a word in meetings to a checklist with owners. The same clean-session method is the one I later used in my public AI hospital recommendations study.

I would run the first audit before anyone debated tools or vendors, and I would bring the team that maintains doctor profiles in on day one rather than after the first audit showed how many errors started there.

• Generative engine optimization: how a hospital gets cited by AI search
• What AI assistants say about your hospital, and how to check
• Study: what AI assistants recommend when Indians ask for a hospital
• Tool: AI search visibility audit

Patient enquiries arrived on WhatsApp, web chat and the phone, often in Hinglish or a regional language, often typed by a family member in a hospital corridor. After one good demo there was pressure to put a conversational agent everywhere at once: website, app, WhatsApp, phone menu and map listings.

I scoped the assistant by allow-list. It answered a short, enumerated set of non-clinical intents, such as doctor availability by unit, directions, visiting hours, insurer and TPA questions, and appointment or report status, and handed everything else to a person with the conversation attached. A one-page never-answer list was signed by the medical director, the data protection lead and me. Acuity detection ran before intent classification on every message, deliberately over-sensitive.

• I defined what counts as an incident, in tiers, in the first week, and reported near misses weekly. Teams that track only accuracy optimise the average; the risk lives in the tail.
• Success was measured as resolution (did the patient’s intent get fulfilled in this channel, in this session) instead of containment, which only counts conversations that ended without a human.
• The assistant was wired into appointment and report systems, because a bot that cannot book is a menu with extra steps.
• The model classified and routed; it never assessed symptoms or severity.
• The trade-off: a higher handover rate that commercial teams read as failure. I took that argument rather than widen the allow-list.

Steering committee questions moved from “how accurate is it” to the shape of the tail and the escalation path. The team stopped optimising menu trees and started optimising the top intents, and found the intents where a fast handover resolves the request better than any bot.

In the first year I trusted a green containment dashboard; once we classified the logs, loops and silent abandons made up much of what it called success. I have also switched an agent off. I would instrument resolution and read real logs before go-live, not months after.

• Putting an AI agent in front of patients without an incident
• Containment vs resolution: the chatbot metric that misled us
• Using AI to triage enquiries without making clinical calls
• Where AI belongs in the patient journey, and where it does not

International demand reached the group through facilitators, direct enquiries and referrals from doctors and sponsors abroad, but only one route was managed deliberately, and often nobody could say which route an arrival had come through. Enquiries lived in messaging threads on individual phones, and the international page on the website spoke vaguely to every country at once.

I moved enquiries onto a verified business WhatsApp number run by a rostered desk, treated the first reply as the product demonstration rather than an admin step, built country pages one market at a time from the questions families from that country actually asked, and changed the unit of measurement from enquiry to arrived patient.

• Facilitator versus direct was decided market by market and specialty by specialty, as channel design rather than a moral argument. Most markets ended up hybrid, by design rather than by drift.
• First-contact route and arrival route were recorded as fixed fields, so the facilitator argument could finally be settled with data rather than conviction.
• The first reply had written rules: what it must carry, what it must never do, a human name, and no clinical opinion in chat from anyone who is not a clinician.
• Country pages were published only in languages the desk could actually answer, with the form built for a weak connection.
• The trade-off: cost per arrived patient is far higher than any cost per lead anyone had reported before, and the first month of that reporting caused arguments.

Families got faster and more specific replies on the channel they had used, and had a page they could forward to the relatives who make the decision. Finance and marketing argued about one number that reconciled with registration, instead of two numbers that never would.

I would fix the arrival count and the route field before touching a campaign or a partner contract. Without them, every debate about facilitators is two sides describing different patients.

• International patient enquiries: how to reply, WhatsApp first
• Facilitator, direct or hybrid: how demand should reach you
• Country landing pages that rank and convert
• Cost per arrived international patient, by market
• Measuring international patient demand honestly

Marketing had grown the way the hospitals had been acquired: one unit at a time. Each hospital had its own manager, its own agency and its own idea of the brand. Units bid against each other on the same search terms, the brand looked different in every city, campaigns that worked in one place never travelled, and nobody at group level could say what a new patient cost.

I split the function into three layers instead of seizing it all at once: platform and standards fully central; programmes designed centrally and run locally; local presence fully local. The agency roster was redesigned as a hub with local partners. And before proposing what the centre would take, I circulated the list of what it would not.

• Announcing what would stay local turned the proposal from a land grab into a division of labour, and cost nothing the centre actually needed.
• The centre ran the mechanics of media buying (rates, accounts, fraud controls), not the decision about what each unit promotes.
• One medical review route for all patient-facing content, whichever agency produced it.
• Brand architecture was treated as an entity decision for search, maps and reviews, not only a positioning debate.
• A service-level promise to units and a short monthly review per unit with one fixed item: what the unit needs from the centre. The trade-off: it took longer, because it had to be earned rather than imposed.

Units stopped competing with each other in paid search, campaigns that worked in one city could be adapted in another, and the group could discuss cost per new patient across units in one format. Unit heads had a forum where the centre was accountable to them.

At one group I tried to do the contested work first, because the business case was obvious and the waste was real. Being right was not enough: the proposal became something to negotiate rather than a service to adopt. I would start with services units want, then earn the rest.

• Centralised vs decentralised marketing: a guide for hospital groups
• Running agencies across multiple hospital units: the roster model
• Brand architecture across a multi-unit group
• Building a digital team inside a hospital group