Using AI to triage enquiries without making clinical calls
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.
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 here overlaps with what I wrote in when automation should not answer the phone: some moments belong to people, and the design should make that the easy path.
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.
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.
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.
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.
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.
