The hospital website is a booking product, not a brochure

A hospital website earns its place by producing confirmed, honoured appointments. Treat the hospital website booking journey as a product: fix doctor profiles and location pages first, replace callback forms with real slots where schedules allow, build for mobile and regional languages, join web data with appointment data, and give one person ownership of the booking outcome.

Open almost any hospital website in India and you can tell who it was built for. The home page carries a carousel of accreditation badges, a message from the chairman, a collage of the building at dusk and a news section last updated during the previous financial year. The one thing a visitor came to do, which is book a doctor, sits behind three menus and a form that asks for their date of birth before it shows a single slot.

That website was built for the hospital. It should have been built for the person trying to see a doctor this week. The shift I push for in every growth team I work with is to treat the hospital website booking journey as the product, and everything else on the site as supporting material. It sounds like a design decision. It is really an ownership, measurement and operating decision.

The brochure habit and where it comes from

Hospital websites grew up as corporate communications assets. They were commissioned by brand or corporate communications teams, approved by the promoter or the managing director, and judged on whether they looked as impressive as the building. Their job was to reassure: we are large, accredited, modern and trustworthy. That job still matters, but it is no longer the main one.

Most visitors today arrive from a search engine, Google Maps or an AI assistant with a specific intent. They want a particular doctor, a particular specialty near them, a price for a health check, or visiting hours. Very few arrive at the home page and browse. They land deep, on a doctor profile or a specialty page, and decide within seconds whether they can get what they came for.

The brochure habit shows up in small ways. Doctor profiles that list degrees but not OPD days. Specialty pages written as medical encyclopaedias with no way to book. Phone numbers that ring a general switchboard. Forms that submit into an inbox nobody monitors on Sunday. None of these are design failures. They are symptoms of a site nobody owns as a product.

What treating the hospital website booking journey as a product means

A product has a user, a job to be done, a measurable outcome and an owner who is accountable for improving it. Apply that to the hospital website and the questions change. Who is trying to book, and from which page? What stops them? How many who start a booking finish it? How many of those actually turn up? Who wakes up in the morning responsible for that number?

In practice, it means a named product owner inside the digital team with authority over the booking flow, a small backlog of improvements ranked by their effect on completed bookings, and a regular release rhythm. It means analytics set up to follow a visitor from landing page to confirmed appointment, not just to count page views. And it means the contact centre, the OPD front desk and the scheduling system are treated as parts of the same product, because from the patient’s side they are.

It does not mean the brand disappears. A well-built booking product is itself a brand experience. Being able to see a doctor’s real availability and book in a few taps says more about a hospital than any tagline.

The five pages that carry most of the load

When I look at where booking intent actually lands on hospital sites, the same few page types come up again and again. These are the ones to fix first, in roughly this order.

1. Doctor profiles. The highest intent page on the site. It should show the photo, specialties, languages spoken, OPD days and unit, live slots and a single clear booking action above the fold.
2. Specialty and condition pages. Visitors here know the problem but not the doctor. Show the relevant doctors with availability, not a wall of text.
3. Location pages. For multi-unit groups, each unit needs its own page with directions, parking, timings and the doctors who sit there.
4. Health check packages. Here the visitor is buying a defined product. Price, inclusions, preparation and a date picker belong on the page.
5. The booking confirmation page. Often ignored, yet it decides whether the patient turns up. It needs directions, what to bring, how to reschedule and a WhatsApp confirmation.

Everything else, from the chairman’s message to the awards page, is supporting content. Keep it, but stop letting it set the agenda for the site.

Slots, not forms

The single biggest improvement most hospital sites can make is to replace the “request an appointment” form with real slot booking. A form is a promise that someone will call back. A slot is a confirmed appointment. The patient experience and the conversion economics are completely different.

The objection I hear is always the same: doctors’ schedules are too fluid, the HIS does not expose availability, OPD staff overbook manually. All true in many places. But the answer is to fix the scheduling discipline, not to hide the problem behind a callback form. Start with the doctors whose schedules are stable. Expose their slots, even if only for a few days ahead. Let the rest remain as callback requests for now, with a visible promise about how quickly the call will come.

Where callback forms remain, treat them as a service with a timer. The best teams I have seen route every web enquiry to the contact centre with a response standard measured in minutes during working hours, and publish the performance weekly. The number that tells you whether this works is not form submissions. It is the one I have written about before in enquiry to appointment: the number that matters.

After the slot is booked

A booking product does not end at the confirmation screen. The appointment still has to happen, and in most OPDs a noticeable share of booked slots go unused because the patient forgot, changed plans or could not find a way to move the appointment. Every one of those empty slots is a cost the brochure website never had to think about.

The fixes are unglamorous. A confirmation on WhatsApp immediately after booking, with the doctor’s name, unit, date, time and a map link. A reminder the day before, and another on the morning of the appointment for early slots. A one-tap option to reschedule or cancel, so the slot returns to the pool instead of sitting empty. Clear preparation notes for health checks and investigations, so patients do not arrive and get turned away.

Doctor delays deserve the same attention. When a consultant is running late or has been called into surgery, patients waiting at home would rather know than sit in a crowded lobby. A simple delay message from the OPD desk, triggered by the same system that sent the booking, turns an irritation into evidence that the hospital respects their time. That is brand work, done through operations.

These touches sit across the website, the messaging platform and the front desk, which is exactly why they need one owner looking at the whole journey.

Speed, language and the phone in the patient’s hand

Nearly all booking intent arrives on a mobile phone, often a mid-range Android device on an uneven connection, sometimes held by a relative booking on the patient’s behalf. Pages heavy with sliders, videos and chat widgets loading on top of each other fail that user. Speed is not a technical nicety here. It decides whether the page renders before patience runs out.

Language is the other gap. In most catchments outside the metros, a meaningful share of patients and families are more comfortable in a regional language. A booking flow available only in English quietly excludes them, and they fall back to calling the switchboard or walking in. You do not need to translate the whole site. Translating the doctor profiles, the booking flow and the confirmation messages covers most of what matters.

Then there is the relative. A son in Bengaluru booking for his mother in a smaller city is a common pattern. The flow should let him book for someone else cleanly, send the confirmation to both numbers, and not force him to create an account in his mother’s name.

Where search, maps and AI answers send people

The hospital website no longer controls the front door. Google Maps listings, local search results and AI assistants increasingly answer the first question before a visitor clicks anywhere. When they do click, they arrive on whatever page those systems chose, which is usually a doctor profile or a location page, not the home page.

This is another reason to treat those deep pages as landing pages in their own right. Structured information about doctors, timings, specialties and locations helps search engines and AI assistants represent the hospital accurately. I have gone into the mechanics in getting a hospital cited by AI search. The short version: clear, consistent, factual pages that answer real questions get picked up. Brochure copy does not.

Paid traffic has the same dependency. Sending expensive search clicks to a slow page with a callback form is one of the spend traps that quietly inflates cost per patient. Improving the booking product is often a better use of the next rupee than raising bids.

Measuring the booking product honestly

Page views and sessions tell you almost nothing about a booking product. The metrics I want on a weekly dashboard are simpler and more uncomfortable: how many visitors started a booking, how many completed it, how many callback requests were answered within the promised time, how many booked appointments were honoured, and where along the way people dropped out.

That last point requires joining web analytics with the scheduling system and the HIS. Without that join, the digital team reports bookings, the operations team reports footfall, and nobody can say whether the website is getting better at producing patients. The join is not trivial, and I would not wait for perfection. Even a weekly manual reconciliation for a handful of high-volume doctors tells you more than any analytics dashboard on its own. For the wider question of what can and cannot be attributed, see attribution in healthcare.

Qualitative evidence matters too. Watch session recordings of people trying to book on a phone. Sit with the contact centre for an afternoon and listen to calls from people who gave up on the website. You will find more to fix in those two hours than in a quarter of dashboard reviews.

Who owns it inside the hospital

This is the part that usually decides success. A booking product crosses marketing, IT, operations and the medical administration. Marketing controls the content and traffic. IT controls the HIS and integrations. Operations controls the OPD schedules and front desk. Medical administration controls doctors’ availability. If each owns a piece and nobody owns the whole, the website stays a brochure with a form attached.

My preference is a single product owner in the digital or growth team, accountable for booked and honoured appointments from the website, with a standing working group that includes the OPD operations lead and an IT integration lead. The product owner runs the backlog. The working group clears blockers, especially around schedule accuracy. Unit heads see the weekly numbers for their unit, which is usually what gets doctors’ schedules into the system on time.

The agency relationship changes too. Instead of commissioning a redesign every few years, you want a team that ships small improvements continuously and is judged on the same booking metrics you are.

What to change on Monday

Pick your twenty busiest doctor profiles by traffic. For each, check four things on a phone: are OPD days and unit correct, is there a single booking action visible without scrolling, does that action lead to a real slot or a callback, and does the confirmation arrive on WhatsApp. Fix what you can this week. Most of it is content and configuration, not development.

Next, time your callback forms. Submit a request yourself at a few different times of day and note how long the call takes to arrive. Share the result with the contact centre head without blame, and agree a response standard. The OPD growth checklist is a useful companion for the operational side of that conversation.

Finally, name the product owner and give them the booking funnel as their number. Everything else follows from someone waking up each morning responsible for it.

Questions people ask