Unit head versus group: designing the growth operating model

Every multi-unit hospital group eventually has the same argument. The unit head says the group digital team does not understand her city, her doctors or her payer mix, and that she could do better with her own agency and a fraction of the allocation she is charged. The group function says the unit ran three contradictory campaigns last quarter, has a listing for a doctor who left in March, and would like to know why the contact centre is being blamed for enquiries the unit never called back.

Both are right about the other, which is why the argument never ends on its merits. It ends when someone designs the operating model properly — who owns which asset, what each side is entitled to expect from the other, and how the money moves — and writes it down in a form that survives the next reorganisation.

I have sat on both sides of this table — running marketing for a chain of units, and later as the group function unit heads complained about. This is the model I would design now, asset by asset, and the two ways it fails.

Why this is an asset question, not an org-chart question

The usual approach is to draw the org chart first and argue about the boxes for six months. Start from the assets instead. A hospital group runs on a small number of shared digital assets that generate demand: the website and its search presence, the listings, the CRM and the patient data in it, the contact centre, the paid media accounts, the review profiles, the app if there is one. Each of these has a natural owner, and the natural owner is determined by one question: where does a mistake in this asset cause damage?

If a mistake damages the whole group — a wrong entity in search, a data breach in the CRM, a contact centre script that misquotes prices across ten cities — the asset belongs at the group. If a mistake damages one unit and stays there — a wrong OPD timing for one consultant, a local campaign that flopped — the asset can live in the unit. Most of the assets are shared by nature and most of the content inside them is local by nature. The model has to hold both.

Who owns the website and search

The group owns the platform, the domain, the templates, the technical search health, and the entity — the fact that search engines and AI answer engines understand what the group is, how many hospitals it has and which doctors sit where. This is non-negotiable. I have watched a unit register its own domain, run a separate site for eighteen months, and halve the group’s search authority in a city it had spent years building.

What the unit owns is the content that only the unit knows: doctor profiles and timings, the services actually available at that building, local language versions, the specific packages a unit sells, and the events and camps it runs. Give the unit a fast, self-service way to change those without a ticket to the group. If a unit head waits eleven days to correct a consultant’s OPD days on her own hospital’s page, she will build her own site, and she will be right to.

The service level here is publishing turnaround — hours for factual changes, days for new pages. The group earns the right to own the platform by being faster than an outside agency at the things that matter to the unit.

Who owns the listings

Listings — maps, aggregators, review platforms, directory sites — are where most groups quietly bleed. A large group can have several hundred of them across units and doctors, and nobody owns the whole set.

Ownership should be at the group, for one reason: consistency of the entity. The hospital name, the address format, the phone number that rings into the contact centre rather than a reception desk, the category, the doctor names spelt the same way on every platform. When each unit manages its own, you get five spellings of the hospital name and a number that rings a landline nobody answers after seven.

But the reviews and the local responses belong to the unit. A patient complaining about a billing counter in one city needs a response from someone who can actually walk down to that counter. The group provides the tooling, the response standards and the escalation path for anything touching a clinical outcome or a legal risk. The unit provides the human who replies within a day. The service level runs both ways: listing accuracy within a defined period of any roster change from the group; review response time and the roster changes themselves from the unit.

Who owns the CRM

The CRM is where getting this wrong costs the most and takes longest to repair. The data model, the platform, the integrations with the hospital information system, the consent framework, the deduplication rules and the security posture belong at the group. There is no version of unit-owned CRM that survives the third unit. You end up with the same patient four times over, a consent given in one city invisible in another, and a group funnel assembled from spreadsheets.

Lead ownership, follow-up and local campaigns belong to the unit. A knee replacement enquiry in a Tier 2 city has to be called back by someone who knows which surgeon has capacity this week, what the cashless status is with that insurer, and whether there is a package or a fresh estimate. The group cannot do that from a central desk, and every time it tries, conversion drops.

The service level from group to unit is data availability and uptime: leads visible within minutes, reports on time, an integration that does not break every time the HIS is upgraded. From unit to group it is lead hygiene: leads actioned within an agreed window, statuses updated, the reason for a lost lead recorded rather than left blank. Put the second in the unit head’s scorecard, because without it the group’s funnel reporting is unreliable, and the unit will cite that unreliability as proof the group adds nothing.

Who owns the contact centre

This one splits by function rather than by asset. First response, cross-unit booking, the technology, the quality framework, the scripts for anything touching pricing or clinical claims, and the queue design belong at the group. A shared central queue is the largest efficiency a multi-unit group has available, and the one unit heads most resent, because the agent on the phone does not know that the cardiologist in their building is the one the whole city asks for.

The fix is not to give each unit its own contact centre. It is to give each unit a named escalation path, a unit-specific knowledge base the unit is responsible for keeping current, and a second-line desk inside the unit for the enquiries that genuinely need local knowledge — complex surgical estimates, international patients, corporate accounts. The service level from the group is answer rate, first-response quality and booking accuracy. The service level from the unit is that the knowledge base is current and the second line answers when the group transfers to it. When a unit lets its knowledge base rot and then complains that the contact centre misinformed a patient, the model has failed — but not in the direction the unit head thinks.

The budget split

Three pools of money, kept separate. Mixing them is where the resentment starts.

The first is the platform cost — the site, the CRM licences, the contact centre technology, the listing tools, the analytics stack. This should be a group cost, recovered from the units through an allocation that is transparent and that the units were consulted on. Buried in a general corporate charge, it becomes something every unit head assumes she is paying for and not using. Publish the allocation basis and show the unit what it gets for its share.

The second is the group demand budget — brand, the search programme, the always-on paid media that feeds the shared queue. This should be held centrally and reported to units by unit, so that a unit head can see what was spent to generate enquiries in her city and what it produced. The moment a unit head can see that number, half the argument about whether the group is adding value stops.

The third is the unit’s own demand budget — local campaigns, camps, doctor-specific promotion, regional-language work, the cost of the second-line desk. This should be the unit’s to spend, within group brand rules and using group platforms, and it should be defended in the unit P&L review like any other line. I have seen groups take this pool away entirely and it never holds. A unit head with no discretionary demand budget stops caring about demand and starts blaming the group for everything.

The balance between the pools moves with the group’s maturity — more in the unit while the platform is thin, more at the centre as the shared assets mature. Write down what it is today and when it will be revisited.

The failure mode of too much unit

You will recognise this group by its search results. Three domains for the same brand. A doctor listed at two units who works at neither. Prices quoted one way by the unit’s agency and another by the contact centre. Ten CRMs, or one with ten configurations, and no funnel view anyone trusts. Every unit bidding on the same brand keywords against each other. Aggregators, seeing no consistent counter-party, picking off units one by one with commission terms the group would never have signed centrally. And the data to prove any of this lives in ten places.

The tell is that the group CEO cannot answer a simple question — how many enquiries did we get last month and how many became appointments — without a week of reconciliation.

The failure mode of too much group

This one is quieter and, in my experience, more common in groups that have recently professionalised. The centre owns everything, requests go through a ticketing system, and the unit heads disengage.

The symptoms: doctor profiles months out of date because the unit stopped sending changes. A contact centre booking patients to the wrong building because nobody local corrected the knowledge base. Campaigns built for the metro landing badly in a Tier 2 city where the patient is asking about the cashless list, not the robotic arm. Regional-language content that reads as translated. And a unit head who, asked about digital in her P&L review, says it is a group matter and looks at the CFO.

The group function looks busy and efficient, and the numbers slowly deteriorate because the local knowledge that converts an enquiry into a patient has left the system. The tell is that enquiry-to-appointment conversion varies wildly by unit and the group cannot explain why.

The artefact that makes it hold

The operating model needs to exist as a document short enough that a new unit head reads it in her first week. One page per asset: what the group owns, what the unit owns, the service levels each way, the escalation path, the metric each side is measured on. A second page for the budget: the three pools, the allocation basis, the review date.

Then a standing forum — monthly, an hour, unit heads and the group function, service levels on the table in both directions. Not a marketing review. A review of whether each side kept its promises. When the group missed its listing window, say so. When a unit sat on leads for a week, show it. This is where the model gets defended and adjusted, and where unit heads stop seeing the group as an overhead and start seeing it as a supplier they can hold to account.

If you’re designing this next quarter

• Inventory the assets first. Every domain, listing, CRM instance, paid account and review profile. You will find more than you expect and several nobody owns.
• Apply the damage test to each. Group-wide damage means group ownership of the asset. Local damage means unit ownership of the content inside it.
• Write the service levels both ways. Group to unit and unit to group. A one-way service level is a complaint mechanism, not an operating model.
• Separate the three budget pools and publish the allocation basis before anyone asks for it.
• Give the unit a real discretionary pool and a real self-service path for content. This is what keeps unit heads engaged.
• Put unit-side obligations in the unit scorecard. Lead hygiene, knowledge base currency, review response. Without this the model tilts towards blaming the centre.
• Stand up the monthly forum before the model is perfect.

The model you land on will be wrong in places. The alternative — leaving it unwritten and letting each reorganisation re-litigate it — is how a group ends up with ten hospitals and no demand engine.

Own the platform. Lend the content. Measure both directions. Anything else is just an org chart with opinions.

Questions people ask