Appointment booking agent on WhatsApp

I take the decision away from the model. The book tool is a sub-workflow that re-checks availability and then inserts into a Postgres bookings table that has a unique constraint on doctor and slot start. If two patients race for the same slot, one insert fails and that tool call returns "slot taken" with fresh alternatives. Only after a successful insert do I create the calendar event. The tool then returns a booking ID. The system prompt says the agent may only confirm by quoting that ID. I also dedupe inbound messages on the WhatsApp message ID, so a webhook retry cannot trigger a second booking. I track phantom confirmations as a metric, with zero as the target.

The WhatsApp Trigger receives the Cloud API webhook and drops status events. A Set node pulls out the phone number, message ID and text. Postgres checks whether that message ID was already processed, and an IF node stops opted-out numbers. A Switch reads the conversation mode. In bot mode, the AI Agent loads recent turns from Postgres Chat Memory keyed by phone and calls check_slots for Dr. Rao over tomorrow evening. It replies with options. When the patient picks one, the book tool re-checks the slot, inserts the row under the unique constraint, creates the calendar event and returns a booking ID. The WhatsApp node sends free-form text inside the 24-hour window and quotes that ID.

The patient must not get a confirmation, because the appointment is not fully on the calendar. The tool should first rely on retry-on-fail for transient calendar errors. If the call still fails, it compensates: it deletes the booking row, or marks it failed, so the slot is released. It then returns an error to the agent rather than a booking ID. The agent tells the patient the booking could not be completed and either offers to try again or calls request_human. A scheduled reconciliation job should also look for rows with no matching event, in case the workflow crashed between the two steps. The rule is simple: no event and no ID means no confirmation.

bookings holds booking ID, doctor ID, slot start and end as timestamptz, patient phone, status, calendar event ID, the source message ID and timestamps, with a unique constraint on doctor and slot start. processed_messages holds message ID as primary key and a processing status. conversations holds phone number, mode (bot or staff), the last inbound message time for the 24-hour window, and opt-out status, unless opt-outs get their own table. The chat memory table is managed by the Postgres Chat Memory node, keyed by phone number. A doctors table with schedules can feed the system prompt and check_slots. I would index bookings by phone for reschedule and cancel lookups.

Retry suits transient failures: calendar API timeouts, 5xx responses, rate limits, brief database connection drops and the model call, which also has a gateway fallback. Do not retry validation errors or unique-constraint violations, because they will fail again. The book tool needs idempotency. Suppose the insert committed but the response was lost and the retry hits the constraint. The tool then checks whether the existing row has the same phone number and source message ID. If it does, it returns the existing booking ID instead of reporting the slot as taken. Calendar creation should also check for an existing event ID on the row before creating another, so retries never produce duplicate events.

For slot ownership, the bookings table is the source of truth, because only it can enforce uniqueness transactionally with the constraint on doctor and slot start. The calendar is the view staff and doctors work from, so it must reflect every booking. The write order follows from this: row first, event only if the insert succeeds, and compensation if the event fails. Because two systems can drift, through crashes or manual edits, a scheduled reconciliation workflow compares them and flags mismatches to staff. Making one store authoritative avoids having to resolve conflicts with no clear rule about which store wins.

Handoff is a tool the agent can call. It is triggered when the patient asks for a person, raises anything clinical or urgent, or when tools keep failing. The tool sets the conversation mode to staff in Postgres and posts a Slack alert with a short summary and the patient's number. Before the agent runs, every inbound message passes a Switch node that reads this mode. In staff mode, the message goes straight to Slack and the agent never sees it, so the bot cannot talk over a human. Staff replies go out through the WhatsApp node. A staff action, or an inactivity timeout the clinic chooses, sets the mode back to bot.

I use Postgres Chat Memory keyed by the patient's phone number, with a small window of recent turns. That is enough for follow-ups like "make it Thursday instead". I do not rely on memory for booking facts: the agent calls a tool to list the patient's real bookings, so state never goes stale. For privacy, the prompt forbids collecting symptoms or medical details. Clinical questions go to staff. Memory rows and execution logs have a retention policy, and I restrict execution data saving in n8n where possible. Under India's DPDP Act, I keep only what is needed and honour opt-out and erasure requests. Credentials stay encrypted in n8n, and model calls go through one AI Gateway key.

Time passes between showing slots and the patient choosing one. That can be seconds or hours, and in the meantime another patient, a staff member or a calendar edit may take the slot. This is a classic time-of-check to time-of-use gap. The re-check inside the book tool catches conflicts visible on the calendar, such as staff blocks that never went through the bookings table. The unique constraint on doctor and slot start remains the final guard against two concurrent inserts. The re-check improves the patient experience by failing early with alternatives. The constraint provides correctness. You need both, because a read-then-write check alone cannot stop a race.

They never trust the model's claim about whose booking it is. The phone number comes from the webhook payload, passed into the sub-workflow by the parent workflow, not typed by the model. The first step queries the booking by ID AND phone number. If no row matches, the sub-workflow returns a not-found error and changes nothing. A patient who guesses or invents another booking ID gets the same response as for an ID that does not exist, so the reply leaks nothing. This keeps the authorisation decision in deterministic code. A prompt injection like "cancel booking 1234 for my friend" can make the model call the tool, but the tool still refuses it.

Claim the new slot before releasing the old one. In one database transaction, update the existing booking row's slot start to the new time. The unique constraint rejects the change if the new slot is taken, and the transaction rolls back so the old booking is untouched. If the update succeeds, move the calendar event. If moving the event fails, revert the row to the old slot and report failure. Updating the same row also keeps the booking ID stable, which avoids confusing the patient. Only after both the row and the event agree does the tool return success, and the reply quotes the booking ID and new time from the tool output.

In n8n I use an OpenAI-compatible chat model sub-node with base URL https://ai-gateway.vercel.sh/v1 and an AI Gateway API key stored as an n8n credential. The primary model is one that handles tool calling reliably, named in provider/model form such as anthropic/claude-sonnet-4.5. A fallback model from a different provider, for example an openai model, covers outages or rate limits at that provider. I would test both models against the same evaluation set of booking conversations, because tool-calling behaviour differs between models. The gateway keeps provider keys out of n8n and gives spend tracking in one place, so switching models is a configuration change, not a credential change.

The prompt should hold clinic hours, doctors and specialities, the current date and the clinic timezone, the booking flow, tone and language guidance, the ban on medical advice, and when to call request_human. Anything safety-critical or about correctness must be enforced in code: slot availability, the unique constraint, ownership checks for reschedule and cancel, opt-out filtering, the 24-hour window check and quoting the tool's booking ID in confirmations. A model can ignore or misread instructions, especially under prompt injection. So the prompt shapes behaviour, and deterministic nodes and the database enforce the rules. If breaking a rule would cause harm, I make sure it cannot be broken, not just discouraged.

Three layers. First, the system prompt forbids diagnosis, dosage and treatment advice, and tells the agent to offer an appointment or a human instead. Second, for questions that sound clinical or urgent, the agent calls request_human, which switches to staff mode and alerts Slack. You can add a Text Classifier node before the agent to flag urgent or clinical messages deterministically. Third, a fixed message for emergencies tells the patient to contact emergency services or go to the nearest hospital, rather than waiting for a reply. I would test this with a set of red-team prompts and review transcripts regularly. The goal is a fast, safe route to a person, not a refusal.

The model might try to follow it, but the tools limit what it can do. No tool can list or cancel other patients' bookings. Cancel takes a booking ID and checks it against the caller's phone number from the webhook, so it can only touch that patient's own appointments. The tools also have narrow inputs, so the model cannot pass in SQL or arbitrary calendar calls. The database credential used by tools should have only the rights it needs. For extra safety, cancel could ask the patient to confirm before running. The general principle: assume the model can be manipulated, and design tools so that even a fully manipulated model cannot do serious harm.

Each message triggers its own execution, and in queue mode they may run in parallel. You can get three separate replies, memory turns written out of order, or two agents both trying to book. The unique constraint still stops a double booking, but the conversation gets messy. Options: serialise per phone number with a Postgres advisory lock or a per-phone processing flag, so later messages wait or are merged. Or add a short Wait, then gather all unprocessed messages for that phone and send them to the agent as one turn. Debouncing feels more natural to patients. Either way, correctness stays in the database and ordering is a user-experience fix.

The model cannot know today's date unless you tell it. I inject the current date, weekday and clinic timezone, for example Asia/Kolkata, into the system prompt on each run. Tools accept explicit ISO dates and times, so the model must resolve relative phrases into concrete values, and check_slots echoes the resolved dates back. The reply states the full date and weekday, such as "Tuesday, 14 April, 5:00 pm", so the patient can catch mistakes before booking. Storage uses timestamptz. The calendar and Postgres agree on timezone, and validation in the tool rejects slots in the past or outside clinic hours, whatever the model produced.

It should be short and honest: something went wrong, the clinic team has been told and will follow up, and for anything urgent, call the clinic or use emergency services. It must never suggest that a booking, reschedule or cancellation went through, because the error may have happened before or during that step. Staff get a Slack alert with the execution ID, the phone number and the last message, so they can check the bookings table and the calendar and close the loop. The failed execution is logged. I would also switch the conversation to staff mode, so the bot does not keep retrying with an inconsistent state.

For the webhook, the WhatsApp Trigger uses Meta's verification setup, and payloads should be checked against the X-Hub-Signature-256 header signed with the app secret, so forged requests are rejected. Credentials for WhatsApp, Postgres, Google Calendar, Slack and AI Gateway are stored encrypted in n8n and referenced by nodes, never put in Code nodes or prompts. The gateway means no provider keys live in n8n at all. The Postgres user for tools should only have the table permissions it needs. Restrict who can edit workflows and view executions, because execution logs contain patient messages. Rotate keys when staff leave, and keep the n8n instance behind HTTPS.

Unit-test the tools directly: book with a free slot, a taken slot, concurrent inserts and a retried request. Test reschedule and cancel with the wrong phone number. Replay captured webhook payloads into a staging copy of the workflow, including duplicate deliveries and status events. Build a scripted conversation set covering Hindi and English, relative dates, ambiguous doctors, medical questions, prompt injections and opt-outs, and run it against both the primary and fallback models. Fault-inject calendar failures to check that compensation runs and no confirmation goes out. Use a test WhatsApp number and a separate calendar. Finally, run a pilot with staff watching Slack before full rollout.

A generic tool hands control of the order of steps and the parameters to the model. It could create an event without inserting a booking row, skip the re-check, edit someone else's event, or report success after a failed call. It also exposes a broad credential to whatever the model decides. Purpose-built tools, such as book and cancel with ownership checks, encode the invariants: insert under the unique constraint first, create the event only on success, and return a real booking ID. The model chooses which business action to take, and code decides how it runs. This also makes behaviour testable and easier to audit.

Patients write naturally, with phrases like "anything with Dr. Rao after 6 on Friday?", and an agent handles that, along with reschedules and mixed questions, without rigid menus. The cost is non-determinism, model spend, latency and new failure modes such as misreading dates or prompt injection. This design limits those risks by keeping all side effects in deterministic tools, with constraints and ownership checks. A menu flow is cheaper, predictable and easy to test, but feels clunky and breaks on anything off-script. A hybrid often works well: interactive buttons for slot choice and confirmation, and the agent for understanding free text.

The Cloud API sends status callbacks such as sent, delivered and read for every outbound message, so they can outnumber real patient messages. If they reached the agent, each one would cost a model call, could write junk turns into memory, and might even produce a reply to an event no patient sent. Filtering at the trigger saves executions and model spend. It also keeps the downstream nodes simple, because every item after that point is guaranteed to be an inbound patient message with a sender, a message ID and content. If you need status data, for example to track failed template sends, route it to a separate, lightweight logging branch.

I would use a small table with the WhatsApp message ID as primary key, plus the phone number, a received timestamp and a status such as processing, done or failed. The write is an INSERT with ON CONFLICT DO NOTHING, and it happens before the agent runs. If no row was inserted, the message is a retry and the workflow stops. Doing check and claim in one statement avoids a race where two deliveries both see no row and both proceed. The status column lets a cleanup or error path tell a crashed message from a finished one. Old rows can be purged on a schedule, because Meta retries only within a limited period.

These operations have several steps: verify ownership, change the calendar, change the booking row, and handle partial failure. A sub-workflow keeps that logic in one tested place with a clear input and output contract. The agent sees a single tool with a few parameters instead of a chain of nodes it might misuse. The same sub-workflow can also be called from a staff dashboard or a scheduled job, so behaviour stays consistent. Each sub-workflow gets its own executions, which makes debugging easier. The trade-off is a little overhead per call and more workflows to version, which is acceptable for operations that change patient data.

Start from assumptions the clinic can confirm: messages per day, the peak-hour share and turns per booking. Each inbound message is one execution with a few database queries, one or more model calls and possibly calendar calls. Model latency usually dominates, so executions are long-running but light on CPU. A single clinic can often run on one main instance. I would move to queue mode, with Redis and worker processes, when concurrent executions start queuing visibly, when serving several clinics, or when I want the webhook-receiving instance kept separate from execution work. I would measure peak concurrency and response time instead of guessing, and size workers from those measurements.

Detect clear opt-out keywords such as STOP, along with local-language equivalents, in a deterministic step before the agent, not by asking the model. Record the opt-out with a timestamp in Postgres and send one confirmation that they will no longer get messages, with a way to opt back in. The IF node in step 2 then stops later messages from reaching the agent. Reminders and template campaigns must check the same flag before sending. If an opted-out patient messages again asking for help, the policy could be to route them to staff instead of silently dropping them. That decision belongs to the clinic and should be documented.

Operational: execution success and failure rates, error-workflow triggers, p50 and p95 response time, gateway fallback usage, and model spend from AI Gateway. Business: bookings, reschedules and cancellations per day, the share of conversations handed to staff and why, and booking conversion from enquiries. Correctness: unique-constraint violations, compensation events where calendar creation failed, and reconciliation mismatches between bookings and calendar. Quality: a weekly sample of transcripts reviewed for wrong dates, medical-advice slips and tone. I would alert on spikes in errors or handoffs. For privacy, logs should carry IDs and outcomes, and access to full message text should be limited.

Inputs: doctor ID or name, a start and end date in ISO format, and optionally a time-of-day preference. Validate them, for example by capping the range at a sensible number of days so the model cannot request months. The tool resolves the doctor, reads clinic hours and existing bookings plus calendar blocks, and returns a short list of open slots with exact start times in the clinic timezone and a slot reference. Returning a few options keeps the reply readable on WhatsApp and reduces tokens. Clear errors such as "unknown doctor" or "no slots, nearest free date is X" help the agent recover without guessing.

check_slots reads the calendar as well as the bookings table, so manual blocks hide those slots. The book tool's re-check also looks at the calendar, which catches a block added after the patient saw the options. The unique constraint only covers bookings that go through the table, so manual calendar entries rely on these checks. A scheduled reconciliation job can import or flag events that lack a booking row. A better long-term fix is to give staff a small form or sub-workflow that books through the same tables, so every appointment passes the constraint. Until then, document the risk and check for overlaps during reconciliation.

Use AI Gateway's spend tracking to see cost per model and set budgets. Keep the memory window small, with recent turns only, and keep tool outputs compact, such as a few slots rather than a whole day's calendar. Limit the agent's max iterations so a confused run cannot loop through tools. Drop status events and duplicates before the agent, and handle opt-outs and simple keywords deterministically. Consider a smaller model for classification or extraction steps and keep the stronger model for the booking conversation, but test that tool calling stays reliable. Review cost per completed booking, not just total spend.

Tell the agent in the system prompt to reply in the patient's language and script where possible, and test the chosen models on real samples, including Romanised Hindi, which is common on WhatsApp. Keep tool inputs language-neutral: doctor IDs and ISO dates, not free text. That way "kal shaam 5 baje" still becomes a concrete timestamp the tool validates. Templates for messages outside the 24-hour window must be approved in each language you plan to use. Opt-out keywords need local equivalents. Staff handoff summaries in Slack should be in the language staff read, which the agent can produce when calling request_human.

The window is measured from the patient's last inbound message, but the reply may be sent much later: after a long agent run, after a Wait, after staff take over, or from a scheduled follow-up. If you decide free-form versus template on arrival and the window closes before sending, the free-form send will fail. Checking right before the WhatsApp node sends, against the stored last-inbound timestamp, gives the correct choice. For ordinary replies to a fresh message the result is the same. The check matters for delayed and asynchronous messages. If a free-form send is rejected anyway, the fallback is an approved template.

1. Ahttps://gateway.vercel.app/api
2. Bhttps://ai-gateway.vercel.sh/v1Correct answer
3. Chttps://vercel.com/ai/v1
4. Dhttps://api.openai.com/v1

Why: The blueprint points the OpenAI-compatible chat model node at https://ai-gateway.vercel.sh/v1 with an AI Gateway API key.

1. ABooking ID only
2. BPatient phone and doctor
3. CDoctor and slot startCorrect answer
4. DPatient phone and slot start

Why: A slot belongs to a doctor at a given start time, so uniqueness on doctor plus slot start makes a second booking of that slot fail.

1. ASend the confirmation, then insert the booking row
2. BCreate the calendar event, then insert the booking row
3. CInsert the booking row under the unique constraint, then create the calendar event only if the insert succeedsCorrect answer
4. DAsk the model to confirm, then create both in parallel

Why: The database insert is the transactional guard, and the calendar event is created only after it succeeds, so a rejected slot never reaches the calendar.

1. AThe ID returned by the book toolCorrect answer
2. BThe patient's message ID
3. CThe model's reply text
4. DA random number generated in the WhatsApp node

Why: Confirmations quote the ID the tool returned after a real write, never text the model produced, so a hallucinated booking cannot be confirmed.

1. AA second calendar event
2. BSlot taken, because the constraint fired
3. CThe existing booking ID, after matching phone number and source message IDCorrect answer
4. DA new booking for the next free slot

Why: Idempotency means recognising your own earlier write and returning it, instead of reporting a false conflict or creating duplicates.

1. AOne succeeds and the other gets a unique-violation errorCorrect answer
2. BThe result depends on n8n queue order only
3. CBoth succeed and the later one overwrites the first
4. DBoth fail

Why: Unique constraints are enforced across concurrent transactions, so the second insert waits for the first and then fails if the first commits.

1. ASend a free-form message with an image attached
2. BSend any free-form text message
3. CSend a pre-approved message templateCorrect answer
4. DMessages cannot be sent once 24 hours have passed

Why: Free-form messages are allowed only within 24 hours of the user's last message. Outside that window, the WhatsApp Business Platform requires an approved template.

1. AAdd a Wait node before the agent
2. BDedupe on the WhatsApp message ID stored in Postgres before the agent runsCorrect answer
3. CAsk the model to ignore repeated messages
4. DLower the model temperature

Why: The message ID uniquely identifies each inbound message. Checking it in a durable store before processing makes the workflow idempotent, without relying on model behaviour.

1. ATemplate message replies
2. BMessages containing images
3. CDelivery and read status eventsCorrect answer
4. DMessages from new phone numbers

Why: Status events are callbacks about outbound messages, not patient input, so they are dropped and only inbound patient messages continue.

1. AAsk the model for confirmation
2. BVerify the booking belongs to the caller's phone numberCorrect answer
3. CSend a WhatsApp template
4. DDelete the calendar event

Why: Ownership is checked first so a patient cannot change another patient's booking, even if the model is manipulated.

1. AInvalid date input from the model
2. BA unique-constraint violation on the booking insert
3. CThe calendar API timing outCorrect answer
4. DA booking ID that does not match the caller's phone

Why: Retry suits transient errors like timeouts, while constraint violations and validation failures will fail again on every retry.

1. AA slot-taken error so the agent can offer other slotsCorrect answer
2. BA request to retry the same insert
3. CA handoff to staff in every case
4. DA booking ID anyway

Why: A violation means someone else holds the slot, so the tool reports it and the agent offers alternatives from check_slots.

1. ADoctor ID
2. BBooking ID
3. CWhatsApp message ID
4. DPatient phone numberCorrect answer

Why: Keying memory by phone number gives each patient their own conversation history across messages.

1. ABecause the slot may have been taken between showing and bookingCorrect answer
2. BBecause check_slots never reads the calendar
3. CTo refresh chat memory
4. DTo reduce model token usage

Why: Time passes between check and use, so the re-check catches new conflicts, and the unique constraint handles true races.

1. AConfirm the booking, since the row exists
2. BRelease the slot by deleting or marking the row failed, and tell the patient it did not go throughCorrect answer
3. CLeave the row and say nothing
4. DCreate the event in a different calendar

Why: Compensation keeps the two systems consistent, and the patient never gets a confirmation for an appointment that is not on the calendar.

1. ARows are needed for chat memory
2. BThe row would keep the slot blocked under the unique constraintCorrect answer
3. CWhatsApp requires it for templates
4. Dn8n cannot delete calendar events

Why: While the row exists, the constraint stops anyone else booking that doctor and slot start, so the slot would stay unavailable.

1. AThe Wait node
2. BA tool sub-node
3. CA memory sub-node such as Postgres Chat MemoryCorrect answer
4. DThe Merge node

Why: The AI Agent node takes a memory sub-node, keyed by a session ID such as the phone number, to load and save chat history.

1. Aanthropic/claude-sonnet-4.5Correct answer
2. Banthropic:claude:sonnet
3. Cmodels/anthropic-claude
4. Dclaude-sonnet-4.5@anthropic

Why: The gateway uses provider/model names such as "anthropic/claude-sonnet-4.5" or "openai/gpt-5".

1. AMerge
2. BLoop Over Items
3. CSwitchCorrect answer
4. DWait

Why: Step 3 uses a Switch node on the conversation mode for that phone number to route messages.

1. ATo the Slack channelCorrect answer
2. BTo the error workflow
3. CIt is discarded
4. DTo the AI Agent with a warning

Why: In staff mode the message is forwarded to the Slack channel so staff handle it and the agent stays out.

1. AThe patient explicitly asks for a person
2. BThe patient asks an urgent clinical question
3. CTools have failed repeatedly
4. DThe patient asks which slots are free next weekCorrect answer

Why: Asking about free slots is normal and handled by check_slots, while the other three are the handoff triggers listed in step 7.

1. ASchedule Trigger
2. BChat Trigger
3. CError TriggerCorrect answer
4. DWebhook

Why: Error workflows begin with the Error Trigger node, which fires when a linked workflow execution fails.

1. ALoop Over Items with large batches
2. BExecute Workflow nodes on every step
3. CRunning multiple main instances with SQLite
4. DQueue mode with Redis and worker processesCorrect answer

Why: Queue mode uses Redis to hand executions to worker processes, which spreads load across workers.

1. AIt enforces the unique constraint on bookings
2. BIt removes the need for a system prompt
3. CIt stores chat memory for the agent
4. DOne credential reaches many providers, with fallbacks and spend trackingCorrect answer

Why: The gateway gives one API key for many providers, fallback models and spend tracking, and keeps provider keys out of n8n.

1. AX-Hub-Signature-256Correct answer
2. BAuthorization: Bearer
3. CX-WhatsApp-Token
4. DX-Meta-Verify

Why: Meta signs webhook payloads with the app secret and sends the HMAC-SHA256 signature in the X-Hub-Signature-256 header.

1. AAs free text like "tomorrow 5pm"
2. BAs timestamptz, with the clinic timezone applied when resolving and displayingCorrect answer
3. CAs local time without timezone
4. DAs Unix seconds in a text column

Why: timestamptz stores an exact instant, so the calendar, database and replies stay consistent across timezones.

1. AContext Window Length
2. BBatch Size
3. CTemperature
4. DMax IterationsCorrect answer

Why: Max Iterations caps the agent loop, so a confused run cannot keep calling tools and running up cost.

1. AIt cannot reply until staff approve
2. BAs an approved template only
3. CAs free-form text, since the 24-hour window is openCorrect answer
4. DBy SMS fallback

Why: Inside the 24-hour customer service window, free-form text replies are allowed, while templates are needed only once the window has closed.

1. AHardcoded in Code nodes
2. BIn the system prompt
3. CStored encrypted in n8n and referenced by nodesCorrect answer
4. DIn chat memory

Why: n8n stores credentials encrypted and nodes reference them, which keeps secrets out of workflow logic and prompts.

1. ACode
2. BSwitch
3. CIFCorrect answer
4. DMerge

Why: Step 2 uses an IF node to stop opted-out patients before they reach the agent.

1. ASummarisation
2. BVector Store
3. CHTTP Request
4. DSetCorrect answer

Why: A Set node maps the needed fields from the payload so later nodes work with clean values.

1. AText classifier and summariser only
2. BChat model, memory and toolsCorrect answer
3. CWebhook, Merge and Wait
4. DEmbeddings only

Why: The agent uses a chat model sub-node through the gateway, Postgres Chat Memory and tool sub-nodes such as check_slots and book.

1. AVector Store
2. BSummarisation
3. CEmbeddings
4. DText ClassifierCorrect answer

Why: A Text Classifier sorts input into set categories, which can route urgent or clinical messages straight to staff.