Hospital Website Chatbots: I Tested 27 Indian Sites
Data collected on by Gaurav Phogat. Method, coding rules and dataset are published below.
I opened the chat widget on 27 Indian hospital websites and tried to ask the plain questions a patient or attendant asks every day. Only 9 let me type a question and get a reply without giving anything first. Seven wanted my name or mobile number, four wanted me to accept terms or consent, five offered only a menu of buttons and two were staffed live chat. The 9 open bots answered 39 of 88 captured questions and deflected almost as many.
See every AI in healthcare operations guide in one place.
Last updated: 3 November 2026.
Hospitals are buying chatbots to cut call volumes and catch enquiries after hours. Vendors show demos where the bot handles everything. I wanted to see what a stranger on a hospital homepage actually gets on an ordinary Tuesday, using questions any front desk answers without thinking. No symptoms, no personal details, nothing a bot should find hard.
Key findings
- 27 of 79 hospital websites I loaded (34%) had a working on-site chat widget. At least 22 of the other 52 offered a WhatsApp button instead.
- Only 9 of 27 widgets (33%) let me type a question and get a reply without handing over details or accepting terms.
- 11 of 27 (41%) put a gate first: 7 asked for a name, mobile number or OTP, and 4 asked for terms or consent.
- 39 of 88 replies (44%) from the open bots answered the question. Another 38 (43%) deflected to a form, a number or a menu.
- 7 of 9 open bots gave an emergency number. One replied that a team would contact me shortly, with no number at all.
- 1 of 9 gave a route to a health check price, and that was a brochure link. No bot stated a rupee figure.
- Best bot 9 of 10, weakest 0 of 10. Same questions, same day. The gap comes from setup more than from technology.
How I did this
Sample. I started from a list of about 130 hospital domains: national chains, regional chains, large standalone multispecialty hospitals and teaching hospitals across metros and tier 2 cities, plus a few specialty chains. I checked which homepages responded, then loaded 79 of them in a desktop Chrome browser and looked for a chat widget. Sites that were down, redirected to another brand, or no longer belonged to a hospital were dropped. Every working on-site widget I could open became one unit: 27 in total (11 regional chain, 8 standalone, 5 national chain, 3 teaching; 23 in metros, 4 in tier 2 cities).
The test. On 3 November 2026 I asked each open bot the same 10 questions in English, in one session: OPD timings, cost of a basic full body health check, which doctor to see for back pain, insurance companies accepted, emergency number, hospital address, video consultation, how to get lab reports, visiting hours, and whether the pharmacy is open 24 hours.
Scoring. Each reply got one code. Answered: the fact itself or a direct link to the page holding it. Deflected: a contact form, a request for details, a generic line, a menu, or an instruction to call or email for the fact. Handed to a human: a promise of a representative or a callback, or a choice of agent channels. Wrong or off topic: the reply did not address the question or contradicted itself.
What I did not do. I entered no name, phone, email or OTP anywhere and submitted no forms. I did not accept any terms or consent prompt, and I stopped at those widgets. I did not message widgets labelled as live staff chat, because a real person should not spend time on a test.
Limits. This is a hand-built sample, not a random one. It leans towards larger private hospitals and includes no government hospitals, because I did not load any government sites. The full ten question test covers only 9 bots, so treat those numbers as directional and read the counts, not just the percentages. I could not capture two replies on one bot because the page froze, which is why the base is 88 and not 90. I scored one session on one day, and bots change often. I did not phone hospitals to verify facts, so an answer marked as answered is a reply that looks usable, not an audited truth. A site with a widget that failed to open for me is not counted.
Most chat widgets do not let you just ask
Two thirds of the widgets never reached the point where I could type a question and get an answer. That is the headline for me, more than anything about answer quality.
The seven personal details gates came in a few forms. Some asked for a name in the first message. Others took my first question and then asked for a mobile number, or a mobile number and OTP. One read my question as my name and replied with a thank you addressed to the word “What”, then asked for my mobile. That small moment says a lot about how the flow was designed: it expected a lead, not a question.
The four terms and consent prompts are a different case. One bot opened by saying that continuing meant agreeing to the terms. Three asked for a click on an accept button. One consent message cited the EU General Data Protection Regulation on an Indian hospital site, with no mention of India’s own DPDP Act in that message. Asking for consent is reasonable. Asking before a person has even said what they need, for a question that needs no personal data, is worth rethinking.
The five menu only bots had buttons for appointments and a few flows, and typing got no reply or was not possible. One offered two buttons in total. If the buttons match what a person wants, this works fine. On the options I could see, none of the five covered most of my ten questions.
What happened when I could ask
Among the 9 open bots, answers and deflections came out almost level. The five wrong or off topic replies were more interesting than the count suggests. Two bots from different hospitals answered a question about OPD timings with “All slots are already booked. Please select a different date.” The bot had fallen into its booking flow, so a person asking when the OPD opens was told the hospital was full. One bot answered an insurance question with a paragraph about the hospital’s history. Another answered the address question with a customer care number.
Six of the 9 brought up a contact form during the conversation, usually three fields, in one case five including gender and age, and one longer insurance form. Often the form appeared for a question the same bot could have handled with one line of approved text. That insurance form also appeared with its consent box ticked in advance. If you are preparing for the DPDP Act, that is a setting to check in your own widgets today.
Spread matters here. Per bot, the answered count out of ten ran 9, 8, 7, 5, 4, 3, 2, 1 and 0. The bottom bot gave one canned branch contact list for the last six questions, whatever I asked. The top two linked to or stated specifics from hospital pages, and the best one named its source pages. That lines up with what I wrote about in containment versus resolution: a bot that keeps the person in the chat has not necessarily helped them.
Which questions bots can and cannot handle
Bots did best on facts that sit on every contact page: emergency number, OPD timings, address. They did worst on the questions that drive money and anxiety: cost and insurance.
The emergency result needs care. Seven of 9 gave a number, which is good. But one replied that the team would contact me shortly, and another offered branch numbers with a request to email or call for details. Emergency is the one question where a slow or vague reply has real cost, and it is also the easiest to fix. One gated bot had the right idea: its greeting printed the ambulance and emergency number before asking for anything else, even though it then wanted a mobile number and OTP.
On price, one national chain bot told me it could not share “confidential financial or business information” in response to a question about a health check package. Most hospitals sell these packages publicly, so the reply was probably a guardrail firing on the word cost. It is a good example of why a hospital needs to test its own bot rather than trust a vendor’s default settings. Another bot replied that I should share my phone number to know the price. Only one sent me to a brochure.
Insurance was weak too. Two bots gave a usable list. The rest deflected or missed, even though an empanelment list is exactly the sort of static information a bot handles well.
What this means for hospital marketers
Everything below is about digital operations and brand, not clinical content. Have your medical and compliance teams approve the answer set before it goes live.
- Print the emergency number in the first message. Do this before any menu, form or consent step. It costs nothing.
- Answer first, capture later. None of my ten questions needed personal data. Ask for a number only when someone wants a callback or a booking, as I argue in enquiry triage without clinical calls.
- Load the boring facts. Timings, address, visiting hours, reports process, pharmacy hours and the insurance list can come from one approved page. Link the source in the reply, as the best bot did.
- Fix the fallback. When the bot does not understand, it should give a number or a link and let the person try again. A contact form on every miss teaches people to close the window.
- Keep booking logic out of general questions. “All slots are booked” in reply to a timing question is a flow bug. My OPD booking flow study found the same pattern of forms before value on booking pages.
- State prices factually or link to them. A plain package price or brochure link is generally safer than a discount line. Avoid superlatives and offers, and check against current NMC and ASCI rules.
- Review your consent wording. Use DPDP language, keep boxes unticked, and show the prompt only when you are about to collect data.
- Label the bot honestly. Say it is automated. One bot I saw used a doctor title in its name, which I would change, since people may read it as a registered doctor speaking.
- Run this test every month. Ten questions, one log, fifteen minutes. Vendors change flows and models without telling marketing.
Download the data
The full dataset (CSV) has one row per widget: hospital type, city tier, widget outcome, gate type, the code for each of the ten questions on open bots, count totals and a short note. It contains no hospital, vendor or person names. Collection date is in every row. It is free to reuse under CC BY 4.0 with credit to Gaurav Phogat and a link to this page.
How to cite this study
Phogat, G. (2026). Testing hospital website chatbots: what 27 Indian hospital sites actually answer. gauravphogat.com. https://gauravphogat.com/hospital-chatbot-test-study/. Data collected 3 November 2026. Licensed under CC BY 4.0.
Questions people ask
Sources and further reading
- CC BY 4.0 (creativecommons.org)
Some do. I loaded 79 hospital websites on 3 November 2026 and found a working on-site chat widget on 27 of them. At least 22 of the other 52 offered a WhatsApp button instead. This was a hand-built sample of mostly larger private hospitals, so read it as a picture of that group, not all of India.
The 9 bots that accepted free text answered 39 of the 88 replies I captured, about 44%. Another 38 replies deflected to a form, a phone number or a menu. Results ranged from 9 answers out of 10 on the best bot to none on the weakest.
Many are set up to capture leads rather than answer questions. Seven of the 27 widgets asked for a name or mobile number before answering, and six of the 9 open bots brought up a contact form during the chat. That helps callback volumes but leaves simple questions unanswered.
Emergency number, address, OPD timings, visiting hours, lab report process, insurance list and a route to the right department. None of these needs personal data. Ask for details only when the person wants a callback or booking, and take consent properly under the DPDP Act.
It should not diagnose or advise on treatment. It can route people to a department and give factual hospital information. Have your medical and compliance teams approve the answer set, label the bot as automated, and avoid giving it a doctor title.
Read my takes first in Google Search
