Hace tres meses un centro médico de zona norte de Buenos Aires nos contactó con un problema conocido. Cuatro personas dedicadas casi full-time a responder WhatsApp. Preguntas sobre horarios, confirmación de turnos, consultas sobre resultados, reagendamientos, cambios de cobertura. El volumen: aproximadamente 500 conversaciones por día, con picos los lunes por la mañana.
El problema no era solo el costo. Era que cuando las cuatro personas estaban ocupadas, las respuestas tardaban. Un paciente que quiere confirmar un turno y no recibe respuesta en 10 minutos asume que no llegó el mensaje y llama por teléfono. El equipo de recepción no daba abasto. La reputación online empezaba a sentirlo.
Este post describe lo que implementamos. Cambiamos algunos detalles por privacidad del cliente, pero la arquitectura es la que está corriendo en producción.
Por qué WhatsApp es particularmente difícil
Automatizar mail o un formulario web es relativamente simple: el canal es asíncrono, los usuarios esperan respuesta en horas, y hay una convención social de "respuesta formal". WhatsApp es distinto. La expectativa del usuario es respuesta en minutos. El tono tiene que ser informal, pero no tan informal que suene a bot. Los mensajes son cortos, ambiguos, a veces con audios, a veces con fotos de órdenes médicas sacadas con flash a las tres de la mañana.
Y lo más importante: WhatsApp no permite mandar mensajes libremente. La WhatsApp Business API exige que las conversaciones se inicien desde el usuario o desde templates pre-aprobados por Meta. Cualquier automatización tiene que respetar esa limitación o se arriesga a que le bajen la cuenta.
La arquitectura
El stack terminó siendo bastante simple. Las piezas:
- WhatsApp Business API vía un proveedor BSP (usamos 360dialog, también funciona Twilio o Gupshup). Es el único camino legal para automatizar; no usamos WhatsApp Web ni librerías no oficiales.
- n8n self-hosted en un VPS del cliente, para orquestar los flujos.
- OpenAI (GPT-4o-mini) para interpretar la intención del mensaje y generar respuestas.
- Postgres como fuente de verdad de turnos, pacientes y conversaciones.
- Sistema de gestión de turnos del centro (un software vertical de salud) conectado vía su API.
El flujo principal es así: cada mensaje entrante dispara un webhook de WhatsApp que llega a n8n. n8n busca o crea un registro de conversación en Postgres, agrega el mensaje al historial, y llama a OpenAI con el contexto de los últimos 10 turnos más instrucciones del sistema. El LLM devuelve una respuesta estructurada con dos campos: la respuesta al paciente y una clasificación de intención.
Routing: qué va a IA y qué escala a humano
Este fue el punto más delicado del diseño. Cuando automatizás un canal sensible como un centro médico, la pregunta crítica no es "¿puede la IA responder?" sino "¿qué nunca debería responder sola la IA?".
Definimos tres niveles de intención.
Nivel 1 — Respuesta automática directa. Preguntas por horarios de atención, dirección, cobertura de obras sociales, preparación para un estudio, cómo pedir un turno, recordatorio de confirmación. Son preguntas cuya respuesta es información pública del centro. La IA las responde y cierra el caso. ~45% del volumen total.
Nivel 2 — Automática con acción en sistema. Confirmación de turnos, reagendamientos, cancelaciones. Requieren interacción con el sistema de gestión pero siguen flujos predecibles. La IA sugiere la acción, n8n la ejecuta contra el API, y el paciente recibe confirmación. ~30% del volumen.
Nivel 3 — Escalación a humano. Consultas médicas ("¿puedo tomar este medicamento?"), resultados de estudios, reclamos, cualquier cosa que mencione síntomas graves o urgencias. La IA detecta la categoría, deja un mensaje cordial diciendo que un humano va a responder, y asigna el ticket a recepción. ~25% del volumen.
El sistema de escalación tiene una regla dura: cualquier palabra relacionada con síntomas, urgencia, dolor o medicación dispara escalación automática, aunque el LLM haya clasificado como nivel 1. Es una red de seguridad que admitimos que produce falsos positivos (escala más de la cuenta) a cambio de evitar falsos negativos (que la IA responda algo que no debería).
Lo que pasó los primeros días
Los primeros tres días los pasamos en "modo observación". El sistema leía los mensajes, generaba una respuesta sugerida, y se la mostraba al equipo humano en un panel interno. Los humanos decidían si enviar la respuesta del bot, editarla o ignorarla. Registramos cada decisión.
Al final de los tres días teníamos métricas concretas: 78% de las respuestas del bot habían sido enviadas sin cambios, 15% con ediciones menores, 7% ignoradas y reemplazadas por respuesta humana. Las 7% fueron las que más nos enseñaron. Eran casos donde la IA había dado una respuesta técnicamente correcta pero con un tono que el equipo consideró inapropiado para un paciente ansioso. Ajustamos el system prompt con ejemplos de estos casos y repetimos.
Recién al día 5 activamos el envío automático para nivel 1 y 2. Mantuvimos el nivel 3 en escalación humana permanente.
Resultados a los dos meses
Números reales medidos durante el mes siguiente a la estabilización:
- Tiempo de primera respuesta: bajó de 12 minutos promedio a menos de 30 segundos para el 75% de los mensajes.
- Volumen manejado por humanos: 25% (vs 100% antes). El equipo bajó de 4 personas a 2 personas con tiempo libre real.
- Confirmaciones de turno: 94% de los turnos se confirman ahora automáticamente el día anterior (antes era 60% porque el equipo no llegaba).
- Tasa de ausentismo a turnos: bajó del 18% al 11%, consecuencia directa del punto anterior.
- Reclamos por "no me responden": desaparecieron.
El cliente recuperó la inversión en el cuarto mes, contando solo ahorro de salarios y sin contar la reducción de ausentismo (que representa mucho más en términos de ingresos).
Lo que no resolvió
Tres cosas siguen requiriendo intervención humana y probablemente siempre la van a requerir.
Los audios no los transcribimos todavía. Whisper funciona, pero el costo y la complejidad no justifican el esfuerzo para un 8% del volumen. Los audios se marcan como "requiere revisión" y alguien los escucha.
Las consultas complejas sobre cobertura de obras sociales (donde el paciente manda la credencial y pregunta por una práctica específica) requieren chequeo contra el nomenclador, que no está en ningún sistema. Se escalan siempre.
Las situaciones sensibles (reclamos, quejas, situaciones familiares) las identificamos y desviamos a humanos por diseño. No es una limitación técnica; es una decisión de producto. Un reclamo merece una persona, punto.
Recomendaciones para rubros similares
Si estás pensando en algo parecido para tu negocio, estas son las decisiones que más nos ayudaron:
Empezá en modo observación. Los primeros tres a cinco días, que la IA sugiera y los humanos decidan. El aprendizaje que sacás de esa semana vale más que un mes de desarrollo a ciegas.
Escalación por defecto, automatización por excepción. No al revés. En salud, finanzas y legales, es más barato escalar de más que responder algo incorrecto.
Medí calidad con ojos humanos, no con métricas automáticas. Las métricas automáticas (sentiment, length, response time) son indicadores, no verdad. Cada semana el equipo de ops revisa una muestra aleatoria de conversaciones y nos pasa las que salieron mal.
Respetá las reglas de WhatsApp. Si usás librerías no oficiales, te van a bajar la cuenta en cuestión de semanas. Pagá el BSP, usá templates aprobados, respetá la ventana de 24 horas.
Diseñá para cuando fallan las APIs. El sistema de turnos se cae. OpenAI tiene incidentes. WhatsApp se atora. Tenés que tener un plan para cada uno o vas a estar apagando incendios todos los martes.
El proyecto en total fueron cinco semanas de trabajo, dos de diseño y ajuste fino, y tres de implementación y tuning. La decisión clave no fue técnica: fue definir desde el primer día qué no delegábamos a la máquina. Esa lista hizo el resto del diseño obvio.