Por qué WhatsApp rechaza tu plantilla y cómo evitarlo a la primera

La aprobación de plantillas es donde los proyectos de automatización de WhatsApp pierden su calendario, y casi nunca se diagnostica bien: se presupuesta como "el proveedor va lento" cuando es rework previsible. La mayoría de los rechazos se escriben mucho antes de que alguien pulse enviar —una categoría mal elegida, marketing disfrazado de utilidad, una muestra ausente—. Meta revisa cada plantilla con sistemas automáticos y revisión manual, y publica las reglas que deciden el resultado. Aquí está el árbol de decisión previo al envío, el mapa de rechazo → corrección y el checklist que usamos antes de someter cualquier plantilla.

La categoría decide todo lo demás antes de escribir una palabra

Una plantilla de mensaje es lo único que WhatsApp permite enviar fuera de la ventana de servicio de 24 horas. Ese privilegio exige pasar por una categoría —utilidad, marketing o autenticación— que define qué contenido se permite, cuándo se envía y qué se paga. Elegirla mal no produce un error: produce una plantilla aprobada que no es la que querías.

La regla que lo cambió todo es del 9 de abril de 2025: si declaraste una plantilla como utilidad y WhatsApp determina que su contenido es de marketing, la plantilla se aprueba como marketing. La propiedad allow_category_change ya no hace falta: es el comportamiento por defecto. No te la rechazan por categoría, te la aprueban en la que Meta considera correcta, con su tarifa. Tienes 60 días desde la actualización para pedir una revisión en Business Support Home.

Nuestra regla de entrega no negocia con el copy: la categoría se elige por el trabajo del mensaje, no por el precio que se quiere pagar. Borra las frases promocionales; si el mensaje sigue teniendo sentido, es utilidad. Si necesita la promo para existir, es marketing, y se somete como marketing. Disfrazar marketing de utilidad ya no ahorra un ciclo: garantiza la re-categorización.

El rechazo ya estaba escrito antes del envío

Meta publica las causas de rechazo, y casi todas son verificables en una lectura de dos minutos del borrador: qué lo provoca, cómo se corrige, y si conviene reenviar o reclasificar:

Dos lecturas de esta tabla. Primero: la mitad de las filas se resuelven leyendo el borrador contra la política, sin tocar el botón de enviar. Segundo: INCORRECT_CATEGORY es el único caso donde la pelea no vale la pena. Cuando WhatsApp re-categoriza, el instinto del equipo es borrar palabras hasta que vuelva a parecer utilidad; casi siempre es el camino equivocado, porque el mensaje era marketing. Acepta la categoría, corrige la economía (envía menos, mejor segmentado) y crea una plantilla aparte y transaccional para lo que sí es utilidad. Pelear la categoría con sinónimos consume ciclos de revisión que el calendario no tiene.

Lo que un reenvío necesita que el primer intento no tenía

Reenviar la misma plantilla con la misma preparación produce el mismo resultado. Un reenvío que funciona agrega lo que faltaba:

• Muestras completas. Toda variable necesita un valor de ejemplo realista y todo encabezado con medios su archivo. Las apelaciones exigen muestra; sin ella, no entran en condiciones a revisión.
• La categoría correcta. Si el contenido es de marketing, se somete como marketing desde el primer reenvío; la API permite editar solo la categoría, y esa edición vuelve a pasar por validación y revisión.
• El webhook de estado conectado antes del primer envío. Los cambios llegan por message_template_status_update (con REJECTED e reason) y template_category_update (con new_category y previous_category). Un equipo sin estos webhooks se entera del rechazo por el correo de Meta.
• La comparación category vs correct_category. Un solo GET a la API de plantillas con esos dos campos lista las plantillas que Meta considera mal clasificadas. Revisarla antes de una campaña grande evita la sorpresa de una plantilla clave aprobada en otra categoría.
• La revisión de categoría dentro de su ventana. Si Meta cambió tu categoría y no estás de acuerdo, la apelación tiene 60 días de plazo. En la práctica casi nunca conviene: rediseñar sí.

No existe plazo garantizado de aprobación, pero sí un hábito que elimina la presión: someter el juego completo de plantillas al inicio de la implementación, no en la semana del lanzamiento. La revisión de Meta corre en paralelo al desarrollo; la aprobación deja de ser la puerta del cronograma.

El plan B mientras una plantilla está en revisión

Mientras una plantilla no está aprobada, la ventana de servicio de 24 horas es el único canal de salida: si el cliente te escribió primero, tienes 24 horas para responder con mensajes de formato libre —los mensajes de servicio—. Ese es el colchón operativo de cualquier despliegue: el flujo degrada a respuestas dentro de la ventana en lugar de bloquearse.

Ese colchón ya no es gratis: desde el 1 de octubre de 2026, los mensajes de servicio y las plantillas de utilidad dentro de la ventana se cobran por mensaje entregado, con tarifa por país —el desglose está en nuestro análisis de los mensajes de servicio de WhatsApp y sus tarifas—. El plan B se diseña, entonces, para salir de él rápido.

Tres reglas que siguen funcionando cuando el presupuesto aprieta:

1. Nunca se lanza un flujo cuya salida depende de una plantilla sin aprobar. Se construye el flujo, se somete la plantilla y se lanza con estado APPROVED ("Active - Quality pending").
2. Dentro de la ventana responde el bot; fuera de ella solo sale la plantilla. Si el usuario no escribió en 24 horas y la plantilla no está lista, no hay canal proactivo. Las notificaciones proactivas deben cruzar la puerta de la aprobación, no la del lanzamiento —ver cómo diseñar flujos de WhatsApp que no dependen de una sola ruta de salida—.
3. La aprobación no es el final del ciclo de vida. Cada plantilla arranca en UNKNOWN y sube o baja con el feedback real de los usuarios. Verde envía, amarillo avisa, rojo pausa automáticamente: 3 horas en la primera instancia, 6 en la segunda y deshabilitación en la tercera. Editar una plantilla pausada la devuelve a revisión —deja de enviarse hasta reactivarse— y las pausas por envío acelerado requieren reactivación manual. Una plantilla deshabilitada no se recupera editando: se crea de nuevo. La calidad del contenido no es un asunto de marca, es infraestructura: el peor escenario no es un rechazo, es perder la plantilla que sostiene el flujo en producción.

Checklist previo al envío

Diez puntos antes de someter cualquier plantilla. Si alguno falla, se corrige en el borrador, no en el ciclo de revisión.

1. Se nombró el detonante: acción del usuario (utilidad) o calendario comercial (marketing). La categoría se decide aquí, no después.
2. El mensaje se releyó con las frases promocionales borradas: si sigue teniendo sentido, es utilidad; si no, es marketing.
3. Ningún marketing quedó escondido en una plantilla declarada como utilidad —desde 2025 Meta la aprueba como marketing igual.
4. Si es un OTP, va como autenticación: sin URLs, sin medios, sin emojis, parámetros de 15 caracteres máximo.
5. Toda variable tiene un valor de muestra realista; todo encabezado con medios tiene su archivo adjunto.
6. Cero identificadores sensibles completos: sin números de tarjeta, cuentas bancarias o cédulas completas, y sin documentos.
7. Cualquier mención de precio u oferta cumple la Política de Comercio de WhatsApp.
8. El nombre del template es único en la cuenta y por idioma (minúsculas y guiones bajos).
9. El webhook de estado de plantillas está conectado y probado antes de la primera sumisión.
10. El juego completo de plantillas se sometió al inicio de la implementación, y el plan B dentro de la ventana de 24 horas —con su costo por mensaje— está listo para el periodo de revisión.

Ese trabajo previo convierte la aprobación de plantillas de una lotería en una fila de tareas. Ningún paso requiere contactos especiales: requiere leer la política una vez y someter preparado. En nuestro trabajo de automatización y chatbots este checklist corre antes de cada sumisión, y es la razón por la que los calendarios de despliegue de WhatsApp sobreviven a la revisión de Meta. Cuando el proyecto no puede absorber ese aprendizaje, la alternativa no es apretar al proveedor: es revisar el flujo completo de entrada a WhatsApp, de la capa de intake al CRM y el traspaso de bot a humano cuando la plantilla aprobada entra en producción.