Hospital Management Software Demo: What to Ask

A vendor demo is a performance. It has been given a hundred times, on data chosen because it behaves, by someone who knows exactly which button not to press. That is not dishonest — it is what a demo is. Your job is to un-rehearse it.

The short version:

1. Make them do your work, live, on a screen. Four tasks, timed, clicks counted. Not a feature tour.
2. Ask which features are live for a paying hospital today, and which are still being built. How plainly a vendor answers that predicts how they will behave after you sign.
3. Ask how you get your data out, in the first meeting, before you are attached to anything.

Everything below is the detail.

Before the call: three things to send the vendor

Send these two days ahead, in writing. A vendor who prepares against them is already demonstrating something useful.

• Your four most common tasks, in your words. For most Indian hospitals that is: register a walk-in and produce a bill, see a repeat patient and print a prescription, correct something that went wrong, and close the day’s cash.
• The shape of your data. How many doctors, how many patients on your busiest morning, how many price lists, which payment modes, which languages the desk actually uses.
• A request for a sandbox login you can use yourself afterwards. Ask now, so a refusal arrives early rather than after you have spent three weeks on the relationship.

Also ask who will be on the call. A pre-sales engineer who can drive the product is worth an hour. A sales manager reading a deck is worth fifteen minutes.

Make them do it live, on a screen

Let the prepared tour run for the first half hour. It tells you what the vendor believes their strength is, and interrupting it only produces a worse version of the same tour. Then take the hour back.

Task one: a walk-in, end to end

“A new patient walks in. Register her, put her in the queue for Dr. Sharma, and give me the receipt.” Then ask for the numbers: how many screens, how many clicks, how many seconds. Do it a second time yourself if you have the keyboard.

Watch for what the system demands that your desk cannot supply at speed — a mandatory address, an email, an identity document, a referral source. Every required field that your receptionist does not have in hand at 9am becomes a fake entry within a week, and fake entries are how a patient database rots.

Task two: the patient who comes back

“She returns in three months. Find her.” How is she found — phone, name, registration number? What does the doctor see first: the last visit, or an empty screen? How many actions to repeat the previous prescription with one change?

This is the task that separates products, because it is the one a demo is least often built around.

Task three: something goes wrong

This is the most informative fifteen minutes you will spend. Ask for:

• A bill raised against the wrong patient, and then corrected
• A payment refunded, and what record that leaves
• A prescription printed with a mistake, and reissued
• A duplicate patient created, then merged

Real hospitals are mostly corrections. A product built only for the clean path will show strain here, and you will see the demonstrator hesitate, which is a more honest signal than anything on the slide.

Ask what the correction leaves behind. Can anyone quietly change yesterday’s bill, or does a change leave a trace of who made it and when?

Task four: the end of the day

“It is 8pm. Show me what we collected today, by payment mode, and what is still outstanding.” If that takes more than one screen, the owner will never look at it, and a number nobody looks at is not a control.

The questions that separate a product from a slide

”Which of these is live for a paying hospital today, and which is being built?”

Ask it directly, screen by screen if you need to. Almost every vendor in this market has a roadmap, and there is nothing wrong with one. What matters is whether they will name the line between today and later without being pushed.

Here is our own answer, so you can see what the shape of an honest one looks like. Arko Care runs the whole outpatient department today, in a real hospital: walk-in registration with a permanent UHID, the token queue, consultation notes, prescriptions on the hospital’s own letterhead with one tap to send on WhatsApp, each doctor’s most-prescribed medicines as one-tap chips, billing with a receipt number against every payment, refunds in three recorded steps, and Day Close showing the money actually collected by payment mode. Inpatient, laboratory and pharmacy modules are not live today. The AI assistance inside the consultation is being built now:

In build now It rolls out with our next hospitals.

A vendor who answers that way is telling you how they will behave when something slips. A vendor who answers “everything you saw is available” and then cannot show you one of those screens on a live system has told you the same thing, less usefully.

”Show me the version we would be given”

Demos are sometimes given on an internal build, a larger client’s customised instance, or a design prototype. Ask whether the screen you are looking at is the one that would be configured for your hospital, and whether any of it requires custom development quoted separately.

”What does it look like with our name on it?”

Ask to see the prescription, the bill and the login screen carrying your hospital’s name and logo rather than the vendor’s. Patients and staff see those three surfaces more than any other. Ask specifically whether your hospital gets its own web address, or whether staff log in to a page branded with the vendor’s name — and whether changing the logo later is a support ticket or something you control.

”What happens when the internet drops in the middle of a bill?”

Every Indian hospital loses connectivity. Ask the vendor to describe the exact behaviour: does the half-entered bill survive, does the receipt number get consumed, what does the receptionist see, and what does she do with the patient standing in front of her. Ask what they tell hospitals to do during a longer outage. A vendor who has no answer has not been in enough hospitals.

”Who owns the data, and how do I get it out?”

Ask in the first meeting, not the last. In what format, on what notice, at what charge, and is that written into the contract or is it goodwill? Where is the data stored, and in which country? What happens to it after termination, and when is it deleted?

The reason to ask early is that the answer is cheap to give while they are still selling and expensive to extract later — which is the whole subject of how to switch hospital management software.

”What is in the number, and what is billed on top?”

Before any figure is useful, get the list: implementation, data migration, training, custom reports, integrations, additional users, annual support, version upgrades, and what happens to the price at renewal. Two quotes are not comparable until both lists exist. Most unhappy software relationships in this market are arguments about the second list, not the first.

”Who answers the phone at 10am on a Monday?”

Not the SLA document — the person. Ask for the support path by name and channel, the hours, what counts as critical, and what happened the last time a hospital’s billing was down during an OPD rush. Then ask for two reference hospitals of roughly your complexity, and actually call them. Ask the references one question the vendor cannot coach: what took longest to fix?

”What can we change without you?”

Fees, doctors’ consulting days, service names, discount limits, the letterhead. If every routine change is a support ticket, the product’s quality matters less than the vendor’s queue length.

Red flags you can spot in the room

• Demo data that is too clean. No duplicates, no misspelt names, no half-finished visits. Real data is ugly; a product that has only met tidy data will meet yours eventually.
• The tour never leaves the happy path. Every deviation you propose is deferred to “we can cover that in the next session”.
• Slides where you asked for a screen. One screenshot is a design. Two is a pattern.
• “We can build that.” Sometimes true and worth having. Ask for it in writing, with a date, with a price, and ask who else asked for it and got it.
• No sandbox. A vendor who will demonstrate but never hand over the keyboard is protecting something — usually the speed of the product in unfamiliar hands.
• Named hospitals, no introductions. Anyone can put a logo on a slide. Ask to be connected to one.
• Certification language that nobody will define. Ask what a standards claim means concretely and which version of which specification it refers to. For digital health standards the primary source is ABDM itself, and our own position on it is on the integrations page.
• Reluctance to say what is not built yet. By this point in the page, you know why.

After the demo: one page, the same evening

Score it before the impression fades, on the same page for every vendor:

What to record	What good looks like
Task 1 — walk-in to bill	Clicks and seconds, written down
Task 2 — repeat patient	Found in one search; last visit visible without hunting
Task 3 — the correction	Done live, leaves a trace of who and when
Task 4 — day close	One screen, by payment mode
Live vs being built	A plain list, given without being pushed
Branding	Your name and logo seen on prescription, bill and login
Connectivity loss	A specific described behaviour, not a reassurance
Data exit	Format, notice period, charge — and whether it is in the contract
Costs on top	The full list, in writing
Support	A named path and two reachable references
What they refused to show	Write it down. It is the most predictive line on the page

Two demos a week apart are compared from notes, not memory. The last row is the one people skip and later wish they had kept.

For the wider evaluation — modules, scale, localisation, total cost — the companion piece is how to choose hospital management software. If the vendor’s proposal is dense with acronyms, the vocabulary is in HMS, HIS, EMR, EHR, and the line-by-line version of what to insist on is the features checklist.

Arko Care is an AI-native, white-label hospital management system for Indian hospitals: your hospital’s name, logo and own web address on every screen, prescription and bill. Book a demo and use the tasks above on us — we would rather be measured that way.