El cambio de pricing de Meta obliga a los ISPs a revisar cómo utilizan WhatsApp.
La reacción más inmediata puede ser: “Entonces saco WhatsApp del omnicanal.”
Pero para un ISP esa decisión puede ser más complicada de lo que parece.
Porque hay una característica de WhatsApp que muchos canales alternativos no tienen: el cliente puede utilizarlo aunque haya perdido su conexión a Internet.
Y eso cambia completamente la estrategia.
El problema de los dos tipos de caída
Imaginemos que un cliente pierde el servicio.
Caso 1: no pagó su factura
En este escenario, un ISP puede utilizar un portal cautivo. Aunque el servicio esté suspendido, se puede permitir acceso a determinados dominios para que el cliente:
- Consulte su deuda
- Descargue su factura
- Realice el pago
- Solicite la reconexión
Caso 2: el servicio se cayó por una falla de red
Aquí cambia todo. Si existe una falla física, no hay Internet para entrar al portal. El cliente no puede utilizar:
- El portal de clientes
- El chat web
- El web inbox
- La página del ISP
En el caso 1, el portal cautivo tiene mucho sentido. En el caso 2, el cliente necesita utilizar otra conexión. Normalmente: sus datos móviles.
Y en ese momento WhatsApp tiene una ventaja enorme como canal de contingencia.
Por eso no existe un reemplazo perfecto de WhatsApp
Hay varias alternativas que los ISPs están explorando.
1. Web Inbox
Permite centralizar la atención directamente desde la página web. Es una buena alternativa para usuarios que tienen conectividad.
El problema: no resuelve completamente una caída de Internet.
2. Portal cautivo
Es excelente para suspensión por falta de pago. Puede convertir una suspensión en una oportunidad de recuperación de cartera.
Pero tampoco reemplaza WhatsApp para una falla física.
3. Telegram
Es técnicamente viable y puede funcionar como canal adicional.
El problema es la adopción. Para muchos ISPs de LATAM la objeción es sencilla: “Mis clientes no usan Telegram.”
No puedes solucionar un problema de atención enviando al cliente a un canal que no utiliza.
4. Facebook Messenger e Instagram
Son canales que ya forman parte del ecosistema digital de muchos ISPs. También pueden ser muy útiles para ventas y atención.
Pero su presencia no significa necesariamente que sustituyan el papel de WhatsApp como canal principal.
5. WhatsApp Calling
Otra posibilidad es utilizar llamadas de WhatsApp para determinados escenarios. Puede ser especialmente interesante cuando la prioridad es establecer comunicación de voz sin depender de la conectividad fija del abonado.
Pero sigue siendo una pieza más dentro de la estrategia, no una solución completa.
Entonces, ¿qué hacer?
La respuesta probablemente no sea: “Eliminar WhatsApp.” La respuesta puede ser: “Usar cada canal para el problema que resuelve mejor.” Por ejemplo:
| Canal | Para qué |
|---|---|
| Soporte, ventas inbound y atención cuando el cliente inicia la conversación. | |
| Portal cautivo | Pagos, reconexión y gestión de clientes suspendidos. |
| Web | Autoservicio, documentación, preguntas frecuentes y operaciones que requieren conectividad. |
| Instagram / Messenger | Adquisición y canales complementarios. |
| Telegram | Canal adicional para determinados segmentos de clientes. |
¿Y dónde entra la IA?
Aquí aparece una segunda decisión.
Un ISP puede automatizar la atención de WhatsApp utilizando modelos propios o utilizar soluciones nativas del ecosistema de Meta. Meta también ofrece Meta Business Agent.
Como referencia de mercado, proveedores que han analizado la documentación de Meta estiman que Business Agent se factura a US$2 por millón de tokens, y que una respuesta típica puede representar alrededor de US$0.04–US$0.05 de consumo. Esta equivalencia es una estimación, no una tarifa fija por mensaje publicada por Meta.
En paralelo, nuestros escenarios actuales con GPT-4.1-mini están alrededor de:
| Conversaciones | Costo de LLM |
|---|---|
| 3.000 | US$75 |
| 5.000 | US$120 |
| 10.000 | US$220 |
Eso equivale aproximadamente a US$0.022–US$0.025 por conversación en estos escenarios.
Pero la comparación importante no es solamente el precio del modelo.
IA genérica vs. IA diseñada para un ISP
Un ISP no necesita solamente responder preguntas. Necesita ejecutar acciones. Por ejemplo:
“No tengo Internet.”
La IA debería poder:
- Identificar al abonado.
- Consultar el estado del servicio.
- Determinar si existe una falla masiva.
- Revisar la ONU / CPE cuando corresponda.
- Crear o actualizar un ticket.
- Guiar al cliente.
- Escalar al equipo humano cuando sea necesario.
“Ya pagué.”
La IA debería poder:
- Identificar al cliente.
- Validar la información del pago.
- Consultar el estado de la cuenta.
- Actualizar el sistema correspondiente.
- Solicitar la reconexión cuando corresponda.
- Confirmar al cliente.
Eso requiere integración con el stack operacional del ISP.
En los ISPs es habitual encontrar sistemas como Wispro, Sae Plus, Infobox, MikroTik, SmartOLT, ISP Cube y otros OSS/BSS, precisamente porque la automatización necesita operar sobre los sistemas que ya utiliza el ISP.
El error es pensar en “un chatbot”
Un ISP no necesita simplemente un chatbot que escriba bonito. Necesita una capa de automatización capaz de conectar:
- Cliente
- Canal
- IA
- OSS / BSS / CRM
- Acción
- Cliente
Y esa arquitectura puede convivir con varios canales.
¿Qué haría un ISP?
Una arquitectura razonable podría ser:
| Pieza | Su papel |
|---|---|
| El canal principal para conversaciones iniciadas por clientes. | |
| Portal cautivo | El canal principal para pagos y reconexiones cuando existe conectividad. |
| Web | Autoservicio y operaciones complementarias. |
| Instagram / Messenger | Ventas y atención complementaria. |
| IA | La capa que automatiza la resolución detrás de todos esos canales. |
El objetivo no debería ser eliminar WhatsApp. Tampoco debería ser enviar absolutamente todo por WhatsApp.
La pregunta que deberían hacerse los ISPs
Después de este cambio de Meta, yo empezaría por cuatro números:
- 1¿Cuántos abonados tengo?
- 2¿Cuántos me escriben cada mes?
- 3¿Cuántos mensajes enviamos por conversación?
- 4¿Qué porcentaje de esas conversaciones puede resolverse automáticamente?
Con esas cuatro variables puedes empezar a modelar el verdadero costo de tu operación de atención.
Porque el futuro del soporte de un ISP probablemente no sea: WhatsApp vs. Web vs. Telegram. Será: WhatsApp + Web + Portal + otros canales + IA + automatización.
La pregunta es cómo diseñar esa arquitectura para que escale.
Comparte este artículo
