What should a clinic automate first, and what should it never automate?

Several vendors have been through your clinic this quarter, and every one of them showed you a demo where a patient books an appointment without anybody at the front desk touching a keyboard. You are the person who actually runs that front desk, and none of those demos told you which parts of your day would survive contact with your real service list.

Here is the short answer. Start with the enquiries your staff already answer the same way every single day, and where the correct answer is written down somewhere you control: opening hours, which branch does what, what a service involves, how a patient prepares for it, what it costs, and when the next slot is. Do not start with anything that amounts to clinical advice or triage, anything that carries a consent boundary, anything your clinic has not actually decided yet, or anything where nobody has agreed to keep the answer current. The second list is what decides whether the first list is safe, and it rarely comes up in a sales meeting because none of it is a feature.

Why repetition plus a written source of truth is the right test

Two conditions have to hold together before an enquiry is worth handing to software. The first is that you answer it repeatedly, because that is where the labour is and where a machine earns its keep. The second matters more: there has to be a document, a system record or a person's decision that says what the right answer is today, so that the answer can be checked, and corrected when it changes. Volume without a source of truth just means you have automated the production of confident guesses at scale.

That second condition also gives you a useful sorting exercise. Take your ten most common enquiries and, for each one, write down where the correct answer currently lives and who is responsible for updating it. Anything where the honest answer is "in one person's head" or "we sort of decided that last year" is not ready. It might become ready in a fortnight once somebody writes it down, which is a perfectly good outcome from the exercise, and cheaper than finding out after go-live.

What goes wrong, in the ways it actually goes wrong

The failures I have seen in clinics are not dramatic. Nobody gets hurt and almost nobody complains. A patient is given the wrong fasting window, turns up, and cannot be scanned, so a slot is burned and the visit has to be repeated.

Someone books at a branch that does not have the equipment for the test they came for, and finds out at reception. A price gets quoted for a package the clinic stopped offering months ago, and now the front desk has to either honour it or start the conversation badly. An enquiry gets answered with "we don't do that" for a service the clinic does in fact do, which is a booking that simply never appears in your numbers, and you will never know it existed. A package gets described as including a test it does not include, and the argument happens on the day.

Every one of those is a wasted visit or a lost booking rather than an inefficiency, and every one of them comes from the same root: an answer that was correct when somebody configured it and stopped being correct when the clinic changed. Your prices move. A package changes what is in it. A machine goes in at one site and not another. The software will not notice any of that, and it will keep sounding exactly as confident as it did in the demo. That is why I care so much about whether an assistant is telling your patients the truth, rather than whether it sounds fluent.

The categories to keep away from it, and why

Clinical advice and triage sit outside the boundary permanently. An assistant can say what a service is and how to prepare for it, and it must not say whether a particular person needs it or what a result means. That line is easy to state and easy to erode, because patients ask the second kind of question in the same breath as the first, and a vendor demo will usually show the assistant being helpful rather than showing it decline.

Consent boundaries are the second category. Requests where the person asking is not the patient, or where a test is being sought on somebody else's behalf, need a human who can judge the situation. Singapore's Personal Data Protection Act governs what you may collect and use and on what basis, and licensing obligations sit alongside it under the Healthcare Services Act. Neither of those frameworks tells you what a scheduling assistant must do, and any vendor who says a framework mandates their product is selling you something else. Treat compliance as something your deployment is aligned to and can evidence, not as a certificate anyone hands you.

The third category is the one clinics find embarrassing rather than risky: things you have not decided. Whether the new package includes the ultrasound, whether the Saturday slot is bookable by anyone or only by follow-ups, whether the second site takes walk-ins. Automation does not resolve an undecided policy, it publishes it.

Questions worth asking, of the vendor and of yourself

• When it tells a patient something wrong, how will I find out? If the answer relies on a patient complaining, you have no detection at all.
• Who updates it when a price or a package changes, how fast does that take effect, and does it need the vendor?
• Can my own staff correct an answer in plain English, starting from the wrong answer itself?
• What does it do when it does not know? A clean handover to a person is worth more than a wider range of confident replies.
• Where do the conversation records live, who can read them, and what do I get back if I leave?
• Which of my top ten enquiries have a written source of truth right now, and who owns each one?

The honest limitation

The hard part of this is not the software, and I say that as someone who builds it. The hard part is that somebody in your clinic has to own keeping the answers current as prices, packages, rosters and site capabilities change, and that ownership usually does not exist anywhere on your org chart today. Automation exposes its absence rather than filling it, because a wrong answer given by a person at the counter gets corrected in the moment, while a wrong answer given by software repeats until someone reads it. If you are choosing between vendors, put a name against that job before you sign anything, and pick the vendor who asks you about it first.