How to Use n8n with ._Template 140 Whatsapp Suporte Multimodal Clinicas

Clinics live and die by their response time on WhatsApp. A patient sends a photo of a rash, a voice note describing symptoms, or a text asking about availability — and if no one answers in the first few minutes, they book with the clinic down the street. The problem isn't staff laziness; it's that front-desk teams can't watch WhatsApp while also checking in patients, answering the phone, and processing payments. Messages pile up, voice notes go unheard, and image attachments get lost in the scroll. Template 140 (WhatsApp Suporte Multimodal Clínicas) solves this by turning n8n into an always-on triage layer that reads text, transcribes audio, interprets images, and routes each conversation to the right place — automatically.

The Problem: Multimodal Chaos on a Single Channel

WhatsApp is the primary intake channel for most clinics in Brazil and Latin America, and patients don't send clean, structured requests. A single inbound thread might contain a voice note, a photo of an exam result, and three fragmented text messages. Human agents have to open each one, listen, read, cross-reference the patient's history, and decide: is this an appointment request, a billing question, or a clinical concern that needs a professional?

That cognitive load is the bottleneck. It doesn't scale past a few dozen conversations a day, and it fails hardest exactly when the clinic is busiest. Worse, unhandled media — a voice note nobody transcribed — becomes invisible. You can't measure or route what you never read. The result is missed bookings, frustrated patients, and a front desk that treats WhatsApp as a burden instead of a revenue channel.

The Solution: An n8n Triage Pipeline That Understands Every Format

Template 140 wires WhatsApp into n8n so that every inbound message — regardless of format — is normalized into structured text, classified by intent, and routed. Text stays text. Audio is transcribed with speech-to-text. Images are described and, when relevant, read with an OCR or vision model. Once everything is text, a single classification step decides what happens next: auto-reply, escalate to a human, or create a task in the clinic's scheduling system.

The key design principle is "collapse to text first, then decide." By converting audio and images into text at the top of the flow, you get one consistent decision point instead of three parallel logic branches. That makes the workflow far easier to maintain and lets you swap models without touching your routing rules.

Step-by-Step Setup in n8n

Here is how the workflow is assembled node by node. Import the template JSON, then configure each stage against your own credentials.

1. Trigger — Webhook node. Set the node to POST and copy the production URL into your WhatsApp Business API provider (Meta Cloud API, 360dialog, or Z-API). Every inbound message hits this endpoint. Keep "Respond" set to "Using Respond to Webhook Node" so you can return a 200 quickly and process asynchronously.

2. Normalize — Switch node. Read the incoming payload's message type field and branch on text, audio, and image. Each branch prepares the media for conversion. WhatsApp media arrives as a media ID, so on the audio and image branches add an HTTP Request node to fetch the binary using your provider's media-download endpoint and your bearer token.

3. Transcribe audio — HTTP Request or OpenAI node. On the audio branch, send the downloaded binary to a speech-to-text endpoint (Whisper via the OpenAI node, or Google Speech-to-Text). Map the returned transcript into a field named content so every branch ends with the same field name.

4. Read images — vision/OCR step. On the image branch, pass the binary to a vision model (an HTTP Request to a multimodal LLM, or a dedicated OCR node for exam documents). Write the description or extracted text into that same content field. Now all three branches converge.

5. Merge — Merge node. Use "Combine" mode to funnel the three branches back into one stream. Every item now carries content (plain text) plus the original patient phone number and message metadata.

6. Classify intent — LLM / Text Classifier node. Feed content into an LLM node with a strict prompt: return one label from agendamento, financeiro, clinico, or outro, plus a one-line summary. Force JSON output so the next node can parse it reliably. This single node replaces the mental triage your front desk was doing.

7. Route — Switch node on the intent label. Scheduling requests go to a Google Calendar or clinic-CRM node to check availability and reply. Billing questions get a templated response with payment links. Clinical concerns are escalated: a WhatsApp reply telling the patient a professional will respond, plus an internal notification.

8. Escalate and reply — WhatsApp Send + notification. Use an HTTP Request (or your provider's node) to send the outbound WhatsApp message. For escalations, add a Slack, Telegram, or email node that pings the responsible staff member with the patient summary and a deep link to the conversation.

9. Log — append to a datastore. Finish every branch with a node that writes the phone number, intent, summary, and timestamp to Google Sheets, Postgres, or Airtable. This log is what lets you measure response time and volume by category.

Benefits You Can Measure

The moment this pipeline is live, three things change. First, no message goes unread — audio and images are transcribed within seconds, so nothing hides in the scroll. Second, response time collapses: routine scheduling and billing questions get an instant, correct answer without a human touching them. Third, your team's attention is reserved for what actually needs a person — the clinical escalations — instead of being fragmented across every inbound ping.

Concretely, clinics running this kind of triage typically deflect the majority of scheduling and billing traffic to automation, cut first-response time from minutes to seconds, and gain a clean dataset showing exactly what patients ask about. That log alone is worth the setup: it tells you whether to hire, where to add self-service, and which questions to pre-empt on your booking page.

Common Pitfalls and How to Avoid Them

Media downloads failing silently. WhatsApp media URLs are short-lived and require your access token on the fetch request. If your HTTP Request node returns a 401 or empty binary, the audio/image branch produces no content and the item slips through as blank. Add an IF node after each conversion that checks whether content is non-empty, and route empties to a fallback reply asking the patient to resend.

Trusting the classifier blindly. An LLM will occasionally mislabel a clinical message as "outro." Never let automation send a definitive medical answer. Constrain the model to routing and templated responses only; anything clinical must escalate to a human. Keep the prompt narrow and always include an explicit "when unsure, choose clinico" instruction so ambiguity errs toward human review.

No idempotency on the webhook. WhatsApp providers retry deliveries, so the same message can hit your webhook twice and trigger duplicate replies. Store each message ID in your log and add an early IF check that drops any ID you've already processed.

Blocking the webhook response. If you do transcription and vision work before returning a 200, the provider times out and retries, compounding the duplicate problem. Respond immediately with the Respond to Webhook node, then continue processing on a separate branch.

Ignoring LGPD. You're handling patient health data. Restrict who can read the log, avoid storing raw audio longer than needed, and make sure any third-party model you call is acceptable under your data-processing agreements. Build compliance into the flow from day one, not after an audit.

Set up correctly, Template 140 turns WhatsApp from your busiest distraction into your most reliable intake system — one that never sleeps, reads every format, and only interrupts your team when a human is genuinely needed.