Using AI to triage enquiries without making clinical calls
Last reviewed
AI enquiry triage means using a language model to read incoming calls, chats, WhatsApp messages and forms, work out what the person wants, and send it to the right desk. Done well, it cuts waiting and misrouting. The design rule is strict: the model classifies intent and routes, it never assesses symptoms or severity, and anything that sounds urgent goes straight to a trained human.
Updated 24 October 2026: merged in our guide on when automation should not answer the phone, and added the harm-versus-annoyance test, escalation design, handoff tooling and clinician review.
See every AI in healthcare operations guide in one place.
The word triage causes trouble in a hospital. To a clinician it means a trained person deciding how urgently a patient needs care. To a contact centre manager it means sorting a queue. When a vendor pitches “AI triage” to a hospital, the two meanings get blurred, and that blur is where the risk lives.
So let me be precise. In this piece, AI enquiry triage means sorting non-clinical enquiries by what the person wants and who should handle it. Appointment, report, bill, cashless approval, international desk, complaint, feedback. It does not mean judging symptoms, and it never means telling someone whether they need to come in.
That boundary is not a limitation to apologise for. It is the reason the project can go live at all. Once the model is kept away from clinical judgement, the remaining problem is a very good fit for language models, and the operational gains are real.
What goes wrong with enquiries today
Most hospitals receive enquiries through more channels than their processes were designed for. Phone lines, WhatsApp, website forms, social media messages, email, aggregator leads, doctor referrals. Each lands somewhere different, and the sorting is done by whoever picks it up first.
The failure pattern is familiar. A message about a pending insurance approval sits in the appointment queue. A report query gets a call-back from a booking agent who cannot open the lab system. A complaint is treated as a routine enquiry and escalates on social media before anyone senior sees it. An international patient writes in Arabic and waits until someone who can read it comes on shift.
Rules-based routing was supposed to fix this. Keyword filters and IVR menus help at the edges, but people do not describe their needs in the words a menu expects. They press the wrong option to reach a human faster. They write “sir please call urgent” without saying why. A patient chasing a reimbursement document and a patient asking for a second opinion can use almost the same words. Sorting that well needs reading comprehension, which is precisely what older tools lacked.
None of this is a clinical problem. It is a sorting problem, and it costs patients time and the hospital appointments. I have written about why enquiry to appointment is the number that matters; misrouting quietly drags that number down, because every hand-off is a place where an interested patient gives up.
What AI enquiry triage should actually do
Language models are good at reading messy text and speech and working out what it is about. They handle spelling mistakes, mixed languages, voice notes turned into text and people who explain their situation in a long paragraph before getting to the point. That is exactly what hospital enquiries look like.
The job I give the model is narrow. Read the enquiry. Identify the intent. Identify the language. Pull out the useful fields, such as the department mentioned, the unit, the doctor’s name if given, the insurer or TPA if relevant, and the patient’s preferred call-back time. Then place the enquiry in the right queue with a short summary for the agent.
It does not answer the patient on its own, at least not at first. It does not decide priority on clinical grounds. And it does not store more than the desk needs, which matters under DPDP when enquiries include health details the person volunteered without being asked.
Designing the intent taxonomy
The taxonomy is the most important design decision in the whole project, and it should come from your data, not from a vendor template. Pull a few weeks of real enquiries across every channel, read a large sample by hand with the contact centre team, and group them by what the person needed and which desk could actually resolve it.
A workable first version for most hospitals looks something like this:
- New appointment, split by department where the desk structure needs it.
- Reschedule or cancel an existing appointment.
- Reports and records, including lab reports, imaging and discharge summaries.
- Billing and estimates, for cash patients asking about package costs or bills.
- Insurance and cashless, covering pre-authorisation status, TPA queries and empanelment.
- International patients, routed to the international desk with language noted.
- Complaints and feedback, routed to patient relations, never to sales.
- Possibly urgent, which is not a clinical category but a safety route, described below.
- Other, for anything the model cannot place with confidence.
Notice what is missing. There is no category for a disease, a symptom or a procedure. Department is captured as a field where the patient names it, because desks are organised that way, but the model is not asked to infer which department someone needs from their symptoms. That inference is a clinical act, even when it looks like admin. If a patient writes about chest discomfort and asks for an appointment, the enquiry goes to the appointment desk with the words the patient used, and a trained person decides what happens next, or the urgent route fires first.
Keep it short. Every extra category makes classification harder and adds a queue someone has to staff. You can split categories later once you see the volumes.
The urgent route: routing, not assessing
This is the section that matters most, and the one I would ask the medical director to sign off personally.
Some enquiries will describe something that might be an emergency. The model must not decide whether it is. Its only job is to recognise that the message contains language the hospital has agreed should never wait in a queue, and to move it immediately to a trained human, with the hospital’s emergency number shown to the person at once where the channel allows.
The list of words and phrases that trigger this route should be written with clinicians, in every language you support, and it should be deliberately over-inclusive. A false alarm costs a nurse or a senior agent a minute. A missed one is the kind of incident that ends AI projects and damages trust in the hospital. I would rather the urgent queue be noisy than ever be quiet by mistake.
The same principle applies to messages about distress or self-harm, to anything involving a child who sounds unwell, and to any enquiry where the model is unsure. Uncertainty routes to a human. It never defaults to a routine queue. The wider thinking, on when automation should not answer the phone at all, is set out in the next section: some moments belong to people, and the design should make that the easy path.
When automation should not answer at all
Triage sorts the queue. A harder question sits next to it: which conversations should a machine never hold, even with a perfect classification? The mistake I see most often is treating automation versus a human team as one decision made at platform selection, rather than a decision made workflow by workflow, patient by patient, sometimes message by message. A patient-relations function is several jobs wearing one job title, and only some of them should ever be handed to a machine.
The harm-versus-annoyance test
I sort every workflow with one question: does a wrong or badly timed message cause harm, or annoyance? A reminder that fires a day early is annoying, easily corrected and forgiven. A message that references a diagnosis, a delayed result or anything with real emotional weight, sent at the wrong moment or in the wrong tone, causes harm, and a follow-up apology rarely repairs it. Annoyance workflows are fair automation candidates, with testing and a feedback loop for misfires. Harm workflows need a person; the only question is how much of the surrounding admin (scheduling the callback, pulling history, flagging the right specialist) you automate to make that person faster.
Where the line falls
- Automation side: booking confirmations, reschedule nudges, routine reminders and recall for stable, low-acuity services such as the annual eye check, dental cleaning or wellness screening, sent only to patients who have opted in under the WhatsApp Business Messaging Policy.
- Human side, without exception: complaint handling beyond an automated acknowledgement, any communication after a serious or unexpected clinical event, any conversation where the patient expressed distress before, and any first response to a negative review. A templated reply to a one-star review reads as exactly what it is.
- The middle band: recall for chronic conditions, post-discharge check-ins after a significant procedure and satisfaction surveys sent close to a difficult admission. My rule: automation can start the contact, but a human owns the response the moment the patient replies with anything other than a plain yes or no.
The cost is asymmetric. Healthcare communication carries a trust premium that automation built for retail or hospitality was never designed to protect. A workflow kept manual a year too long costs some efficiency; one automated too early, badly, costs a relationship with loyal patients that took years to build. On a borderline workflow I keep it manual for one more quarter and watch what the automated version would have said.
Where the humans sit in the loop
In the first phase, every classification is a suggestion. The enquiry lands in the suggested queue with the model’s summary, and the agent who picks it up can correct the intent with a single click. Those corrections are your most valuable data, because they tell you exactly where the model is confused.
Agents also need to trust the summary without relying on it blindly. The original message should always be one click away. Where the summary and the original disagree, the original wins, and the disagreement is logged.
Supervisors need a daily view of the “other” and “possibly urgent” queues and a weekly review of corrections. If the same confusion keeps appearing, such as billing queries being read as insurance queries, the fix is usually to tighten the category definitions or add examples, not to blame the model.
Only when accuracy is steady and the corrections are rare should you consider letting the model send a first acknowledgement to the patient. Even then, it should be a plain message confirming receipt and the next step, reviewed and approved in advance, not a composed answer.
Escalation triggers that actually fire
Every automated step needs a documented escalation path to a human, and the common failure is a path that exists on paper but was never tested with a real patient reply. A bot that recognises “I want to cancel my appointment” but not “I’m scared about what the scan might show” is not a broken chatbot; it is working exactly as designed, on a design that never accounted for that sentence.
- Build triggers around emotional and clinical signal words, not just intent categories.
- Test them against real patient language from old call centre transcripts, not the tidy examples in a vendor demo.
- Route escalations to a named person or small team with response-time accountability, not a general queue.
- Review the near-misses, the escalations that should have fired and did not, at least monthly.
Handoff tooling is usually the real failure
Most handoff failures I have seen were tooling problems dressed up as people problems. The platform sends the escalation to a shared inbox, or a ticket into a system the team has to remember to check, and the patient waits four hours for a reply they expected in minutes on WhatsApp. The team gets blamed for being slow. A handoff that works puts the conversation, with what triggered it, recent history and any open cases, in front of a person on the same channel the patient is using, with a visible response-time expectation. If a shortlisted platform cannot hand off cleanly into the tool your team works from all day, that matters more than any feature on its demo. Test it before signing.
Language, channels and the CRM
Language detection is one of the quickest wins. A model can tell the difference between Hindi, Marathi, Bengali, Tamil and mixed English with far more patience than a tired agent, and it can route to agents who speak the language. For international desks, this alone often changes how quickly overseas enquiries receive a first response.
Channels matter because each carries different context. A WhatsApp message may include a report photo. A form may include a pre-selected department that the patient chose at random. A call transcript may contain two separate needs. The triage step should treat the enquiry as the unit, not the channel, and should flag when one message contains two intents so both are handled.
All of this only works if the output lands in a system agents already use. For most hospitals that is the CRM or the contact centre platform. If the triage lives in a separate screen, agents will ignore it within a week. This is one reason I keep saying a hospital CRM is for managing the whole enquiry, not just storing leads: triage is the front of that pipeline.
Bring clinicians and agents in before launch
What doctors resist, and why they are usually right
Every automation rollout I have run has hit clinician resistance at some point, and the instinct in a digital team is to manage past it. Often it is a legitimate signal that the system is about to say something on the hospital’s behalf that a doctor would never say, in a tone they would never use, to a patient they have a real relationship with. The doctors who push back hardest are usually the ones whose patients trust them personally rather than the hospital brand. Put clinical leadership on template review for anything touching an ongoing condition, not as a courtesy but because they catch tone problems a marketing or operations team cannot see. I once had a consultant flag a “perfectly fine” reminder as one that would make a category of long-term patients feel like a number. She was right, and we changed it.
Positioning the change with the patient-relations team
The realistic end state is a hybrid: automation and triage handle volume and consistency on low-stakes, high-frequency work, and a smaller, better-supported human team handles everything with emotional or clinical weight, with more time for it, not less. Pitched as “automation is coming for your job”, it gets resisted, reasonably. Pitched as “the reminder calls and reschedule follow-ups are moving to automation so you can spend your time on the patients who are struggling”, it gets adopted, because it is true. I have found that framing does more to reduce resistance than any amount of platform documentation.
What to measure, and what to ignore
Vendors will offer a dashboard full of model metrics. Most of them are beside the point. What the hospital cares about is whether enquiries reach the right person faster and whether fewer of them fall through the gaps.
The measures I would track are plain. Agreement between the model’s suggested queue and the queue the enquiry actually ended in. Misroutes caught by agents, grouped by the pair of categories confused. Time from enquiry to first human response, split by intent, because an improvement in appointments can hide a problem in complaints. The share of enquiries landing in “other”, which should shrink as the taxonomy matures. And how often the urgent route fires, with a sample reviewed by a clinician every week.
What I would ignore is any figure describing how much work the model did on its own. “Enquiries handled by AI” is a number that rewards removing humans, and in this design removing humans is not the goal. The trap is the same one I describe in containment versus resolution: a metric that looks like success while patients quietly have a worse time.
Finally, keep one downstream measure in view: conversion from enquiry to booked appointment for the intents that should lead to one. Triage is upstream of revenue, and it should be judged there eventually, even if early months are about accuracy.
For any automated conversation, add escalation rate as a share of automated conversations, watched over time rather than as a snapshot. A rate that falls because the system genuinely handles more is good news. A rate that falls because patients have learned the channel does not listen and stopped trying is a much worse story wearing the same number. So pair it with a monthly read of actual escalated transcripts, not a satisfaction score. You will reliably find conversations that should have escalated and did not, and that is the most useful signal for where to redraw the line next quarter. For a board or CFO, the same applies: watch escalation and complaint trends, not just delivery volume or cost per contact.
Governance, consent and what not to store
Enquiry text is personal data, and frequently sensitive personal data, because people describe their health when they ask for an appointment. Under DPDP, the hospital needs a clear purpose for processing it, a notice that tells people how their information is used, and limits on how long it is kept.
Practical rules I would set: the model processes the enquiry for routing and summary only. The summary should hold what the desk needs, not a full restatement of the person’s medical story. Enquiry data is not used to train external models. Access follows the same rules as the CRM. And the vendor contract states where data is processed and what happens to it afterwards.
Governance also means a named owner. I would put operational ownership with the contact centre head, clinical sign-off for the urgent route with the medical director, and data protection review with whoever holds that role. The approach to putting AI in front of patients without an incident applies here too, even though triage sits mostly behind the scenes.
Where I would start on Monday
Pull a sample of recent enquiries from every channel and sit with the contact centre lead to read them. Draft the intent taxonomy from what you find, keep it short, and agree which desk owns each category. Write the urgent-route phrase list with clinicians, in every language you support, and get it signed.
Then run the model in shadow mode for a few weeks. It classifies every enquiry, but agents work exactly as before, and you compare its suggestions with what actually happened. Measure agreement, misroutes and how often the urgent route fires. Use the enquiry to appointment funnel calculator to set a baseline before anything changes.
Only after shadow mode shows the classification holds up should suggestions go live in the queues. Keep the “other” queue visible, keep the corrections flowing back, and resist every request to let the model start answering clinical questions. The value here was never in the model being clever. It is in the right person seeing the right enquiry sooner.
The full guide: AI in hospital operations in India: a non-clinical risk framework.
Further reading from primary sources
- WHO: Ethics and governance of artificial intelligence for health (2021): global principles for accountable AI in health.
- ICMR: Ethical guidelines for AI in biomedical research and healthcare (2023): India’s guidance on responsible AI in healthcare.
- NITI Aayog: National Strategy for Artificial Intelligence (2018): India’s national framing of AI, including healthcare.
Questions people ask
AI enquiry triage is the use of a language model to read incoming enquiries from calls, chats, WhatsApp, email and forms, identify what the person wants and route it to the correct desk. It covers intent such as appointments, reports, billing, cashless approval, international enquiries and complaints. It does not assess symptoms or clinical urgency. Anything that might be urgent goes straight to a trained human.
No, and the distinction must be explicit in every document and conversation about the project. Clinical triage is a trained professional judging how urgently someone needs care. AI enquiry triage is sorting non-clinical requests to the right team. The model never decides severity. It only recognises agreed phrases that must go to a human immediately, which is a routing rule, not a medical judgement.
You should sign off the urgent-route phrase list in every supported language, the rule that uncertainty always routes to a human, and the wording of any automated acknowledgement a patient receives. You should also be told how often the urgent route fires and see samples of what triggered it. You do not need to approve the operational categories such as billing or reports.
A sensible first phase takes a few months rather than a few weeks. Reading real enquiries and building the taxonomy takes the first stretch, followed by writing and approving the urgent-route list, then a shadow period where the model classifies but agents work as usual. Going live faster usually means skipping the shadow period, which is the part that shows whether the classification actually holds up.
Mostly fewer wasted hand-offs and faster first responses, which protect conversion from enquiry to appointment. It can also reduce the load on senior agents who currently spend time re-routing work. I would not promise headcount reductions in the business case. The more honest case is that the same team handles enquiries better and fewer interested patients are lost to delay or misrouting.
Not at first. In the first phase, it only suggests a queue and writes a summary for the agent. Once accuracy is steady, it may send a simple, pre-approved acknowledgement confirming receipt and the next step. It should never compose answers to clinical questions. Any reply beyond a pre-approved acknowledgement needs a separate decision with clinical and legal review.
Language models handle Hindi, other Indian languages and mixed English reasonably well, and language detection is often one of the fastest gains. The model identifies the language and routes to agents who speak it. The urgent-route phrase list must be written separately for each language with native speakers and clinicians, rather than translated mechanically from English, because people describe distress in their own idioms.
IT needs to connect enquiry channels to the triage step and send the output into the CRM or contact centre platform agents already use. They also need to manage access, logging and data retention in line with DPDP, and review the vendor’s hosting and data handling. The integration usually takes more effort than the model itself, so it should be planned from the start.
Treat enquiry text as sensitive personal data, because people describe their health in it. Define the purpose clearly as routing and response, update notices so patients know how enquiries are handled, keep summaries minimal, set retention limits and restrict access. Make sure the vendor contract states where data is processed and prohibits using your enquiry data to train external models.
Agents are often wary at first, because they assume it is a step towards replacing them. The shadow period helps, because it shows the model as a sorting assistant they can correct. Involve senior agents in building the taxonomy and reviewing corrections. When they see fewer misrouted enquiries landing on them, most become supporters, and their corrections make the system noticeably better.
Compare classification suggestions with agent corrections, track misroutes, time to first response by intent, how often enquiries land in the unclassified queue and how often the urgent route fires. Set a baseline before go-live so you can see change. Avoid measuring success by how many enquiries the model handled on its own, because that pushes the design towards automation rather than correct routing.
Ask how the model is configured for your taxonomy, how corrections feed back, how uncertainty is handled, and whether low-confidence results default to a human. Ask where data is processed and stored, whether it is used for training and how long it is retained. Ask to run a shadow period on your own data before signing a long contract, and be wary of anyone promising clinical triage.
In a well-designed setup, the agent who picks up the enquiry corrects the category with one click and handles it anyway, and the correction is logged. Supervisors review patterns weekly. The damage from a misroute is a short delay, not a clinical error, because the model is never making clinical decisions. That containment is the main reason to keep the scope narrow.
Yes, and groups often benefit more because enquiries arrive centrally but must be resolved by the right unit. The taxonomy then needs a unit field as well as an intent field. Keep the urgent-route rules identical across units, so the safety behaviour does not vary by location, and let unit-specific queues handle the operational differences.
Ask whether a wrong or badly timed message causes harm or annoyance. A reminder that fires a day early is annoying and easily forgiven, so it is a fair automation candidate. A message touching a diagnosis or a delayed result, sent at the wrong moment, causes harm, so it needs a person.
Complaint handling beyond an initial acknowledgement, any first response to a negative review, and any communication after a serious or unexpected clinical event. Automation can schedule the human callback; it should not attempt the conversation itself.
Messages that go out under the hospital name in a tone they would not use, to patients who trust them personally. Involve clinical leadership in template review before launch; their objections often catch real tone problems a marketing or operations team cannot see.
If you are also drawing the automation line for the first time, run this alongside:
- List every patient-facing communication workflow the hospital runs, however informal.
- Sort each by the harm-versus-annoyance test, not by how easy it would be to automate.
- For anything in the middle band, decide who owns the human handoff before you decide which platform to buy.
- Get clinical leadership to review templates for anything touching an ongoing condition, not just new-patient messaging.
- Test escalation triggers against real patient replies from old call centre transcripts.
A hospital that gets this right does not end up choosing between automation and a human team. It ends up with a smaller, sharper human team doing work only a person can do.
Read my takes first in Google Search
