En El Salvador el negocio pasa por WhatsApp. Ahí se confirman las citas, se coordinan los pedidos y se responde a los clientes, casi siempre desde un teléfono que alguien tiene que estar mirando.
La pregunta que nos llega es siempre la misma: "¿se puede automatizar eso?". La respuesta es que sí, bastante, pero no de la forma que la mayoría imagina, y las reglas que lo limitan no son técnicas. Son de Meta, y están diseñadas para que las empresas no puedan hacerle a la gente lo que hicieron con el SMS.
Este artículo es sobre qué permite de verdad la Cloud API, qué condiciona lo que puedes enviar, y qué no vas a poder hacer por más presupuesto que le pongas.
Tres cosas distintas que la gente llama "WhatsApp"
La app de WhatsApp Business. La que se descarga del teléfono. Tiene catálogo, etiquetas, respuestas rápidas y mensajes de ausencia. No se integra con tu sistema: lo que pasa ahí adentro se queda ahí adentro. Para muchos negocios es suficiente y no hay que venderles nada más.
La Cloud API. La vía programática de Meta. Tu sistema envía y recibe mensajes por su cuenta, sin que nadie toque un teléfono. Es lo que hace posible que una cita agendada en tu sistema dispare una confirmación sin intervención humana. Es también lo que exige un desarrollo.
Un BSP, o proveedor de soluciones. Un intermediario que te da una interfaz encima de la API, normalmente con bandeja de entrada compartida, reportes y facturación propia. Ahorra construir, y a cambio tus conversaciones pasan por un tercero y quedas atado a su producto.
La decisión entre los tres es la misma que aparece en software a medida o SaaS: la app es no construir, el BSP es alquilar, la API es construir. Ninguna es la respuesta correcta siempre.
Las plantillas aprobadas son la regla que lo condiciona todo
Esta es la parte que sorprende a todo el mundo, así que conviene decirla sin rodeos: no puedes escribirle a un cliente lo que quieras, cuando quieras.
Para iniciar una conversación tienes que usar una plantilla, y las plantillas se envían a Meta para aprobación antes de poder usarse. Tú defines el texto con variables, ellos lo revisan, y solo después puedes enviarlo. La documentación oficial es explícita en que una plantilla es el único tipo de mensaje que se puede enviar fuera de una ventana de servicio al cliente.
Las consecuencias prácticas son tres, y ninguna es obvia hasta que estás dentro:
Una plantilla nueva no está disponible el mismo día. Si tu operación necesita un aviso que no habías previsto, hay una espera antes de poder mandarlo.
El texto es fijo. Puedes cambiar las variables, no la redacción. Cada variante real de mensaje es una plantilla más que mantener.
Y no todo se aprueba. Lo promocional tiene reglas distintas de lo transaccional, y una plantilla rechazada hay que reescribirla y volver a enviarla.
La ventana de servicio, y por qué te conviene
Cuando un cliente te escribe, se abre una ventana durante la cual puedes responderle libremente, sin plantilla, como en una conversación normal. Fuera de esa ventana vuelves a necesitar una plantilla aprobada.
Esto suena a limitación y en realidad es la parte buena del diseño. Significa que el sistema premia responder rápido a quien te buscó, y encarece interrumpir a quien no. Es exactamente el incentivo que hace que el canal siga funcionando.
Para una operación real la consecuencia es de arquitectura: el sistema tiene que saber si la ventana está abierta antes de decidir cómo mandar un mensaje. Un sistema que no lleva esa cuenta va a intentar responder en texto libre cuando ya no puede, y ese mensaje simplemente no llega.
Lo que sí se automatiza, y lo que no
Se automatiza bien todo lo que es una consecuencia de algo que pasó en tu sistema. Confirmación cuando se agenda una cita. Recordatorio el día antes. Aviso de reprogramación cuando alguien mueve la hora. Notificación de que un pedido salió. Recuperación de una cita cancelada. En los sistemas de agendamiento que hemos puesto en producción, esos cuatro o cinco avisos son la mayor parte del valor, y son también los más fáciles.
Se automatiza a medias la entrada. Los mensajes que te escriben llegan a tu sistema por webhook, o sea que tu servidor los recibe y puede actuar. Un menú de opciones, una consulta de estado o una confirmación por respuesta funcionan bien. Una conversación abierta funciona mucho peor de lo que las demos sugieren, y el diseño honesto es escalar a una persona en cuanto el cliente sale del camino previsto.
No se automatiza la relación. Si tu cliente escribe porque está molesto, ningún flujo lo va a resolver, y el intento de que lo resuelva empeora las cosas. La regla que aplicamos es simple: automatizar lo que es información, escalar lo que es juicio.
Convivencia con el número que ya usas
La objeción más frecuente, y la más razonable: "ese número lo usa mi equipo todos los días".
Un número no puede estar en la app de WhatsApp Business y en la Cloud API al mismo tiempo. Eso deja tres caminos, y conviene elegirlo antes de construir nada, no después.
Puedes migrar el número a la API y darle a tu equipo una bandeja de entrada conectada, de modo que sigan atendiendo pero desde otra herramienta. Puedes usar un número nuevo para lo automático y dejar el histórico para las personas, lo cual es más simple y tiene el costo de que tus clientes ahora ven dos números. O puedes no migrar, si el volumen no lo justifica.
La pregunta que ordena la decisión es cuántos de tus mensajes salientes son avisos que nadie necesita escribir a mano. Si son la mayoría, migrar se paga solo. Si tu operación es sobre todo conversación humana, probablemente no.
Los costos, como estructura
No vamos a poner tarifas, porque envejecen mal y porque las de tu país y tu caso las tiene Meta publicadas. Lo que conviene entender es la forma del cobro, que no es la que la gente supone.
No se paga por mensaje, se paga por conversación. Se abre una ventana de facturación y dentro de ella el volumen de mensajes no cambia el precio. Y las conversaciones que inicia el cliente se tratan distinto de las que inicias tú.
La consecuencia para el diseño es contraintuitiva: agrupar avisos en una misma ventana es más barato que dispersarlos, y un flujo que hace que el cliente escriba primero cuesta distinto de uno que lo interrumpe. Si vas a mandar volumen, esto se modela antes de construir, no después de la primera factura.
Cuándo no vale la pena
Si tu volumen de avisos es bajo, la app de WhatsApp Business y una persona organizada te van a servir mejor que cualquier integración. La Cloud API tiene un costo de construcción y un costo de operación, y por debajo de cierto volumen ninguno de los dos se recupera.
Tampoco vale la pena si el proceso que querrías automatizar todavía no está claro. Automatizar avisos sobre un flujo que cambia cada mes es rehacer plantillas cada mes, con la espera de aprobación incluida cada vez.
Y si lo que buscas es que un bot atienda a tus clientes para no tener que atenderlos, la respuesta honesta es que eso no funciona y que se nota. Esa es una de las preguntas que conviene hacerle a cualquier proveedor que te lo prometa.
Si quieres saber cuál de los tres caminos aplica a tu operación, eso se resuelve en media hora.
Las políticas y el modelo de precios de WhatsApp son de Meta y cambian. Las plantillas, su aprobación, la ventana de servicio y la recepción por webhook se verificaron contra la documentación oficial de Meta al 16 de agosto de 2026. Confirma tarifas y políticas vigentes antes de comprometer un presupuesto.
Si estás evaluando llevar WhatsApp de un teléfono a tu sistema, podemos revisar tu caso contigo. La llamada de descubrimiento dura treinta minutos, es gratuita y sin compromiso, y sirve para descartar el camino equivocado aunque no trabajemos juntos. Puedes agendarla aquí. Lo que construimos en esta línea está en sistemas a medida.
¿Esto aplica en tu empresa?
30 minutos, sin compromiso, para revisar tu caso y decidir si hay algo que construir.